不要将 BLOCK_BUFFER_SIZE 增加太多，因为处理器没有 FPU（浮点单元）- 100 -200 更好？

IMO 将 SEGMENT_BUFFER_SIZE 和 ACCELERATION_TICKS_PER_SECOND 保留为默认值。我没有检查 ACCELERATION_TICKS_PER_SECOND 的影响，AFAIKT SEGMENT_BUFFER_SIZE 无关紧要。

X 轴的步长/毫米设置是多少？

如果你想要高速，没有什么能比得上 Teensy 4.1……

我目前使用 16 微步的 20 齿滑轮。这相当于 80steps/mm。

以 7000mm/min 的速度，这应该等于步进频率：
(7000mm/min*80steps/mm)/60=9,33Khz
所以实际上相当“慢”。
我猜步进脉冲速度不是瓶颈，（因为我可以以 20m/min 的速度驱动机器而不会卡顿）而是 pwm 更新时间？

我不认为原始 CPU 性能会成为问题，因为我发现启用/禁用动态功率缩放不会影响速度。
我猜想如果 cpu 功率是瓶颈，功率缩放所需的额外计算会减慢速度。

我有一个可以测试的 ESP32。它具有 FPU，您认为我会比 SAM3X8E 更快吗？
应该是因为它提供 240Mhz 2core vs 84Mhz，所以理论上大约快 6 倍。
这相当于 42m/min 的光栅扫描速度，这比我的机械师要快。

你有没有关于你的软件与 teensy/ESP32 相结合的能力（光栅扫描速度）的任何信息？

我在 Mac 上使用 Lightburn 的 nativ usb 串行接口。

也试试编程端口——我得到了很高的进给率，但我没有连接电机所以无法判断它是否断断续续。卡顿可能是由于 USB 外设开销/IRQ 优先级造成的。

我有一个可以测试的 ESP32。它具有 FPU，您认为我会比 SAM3X8E 更快吗？

它应该是因为它有一个 FPU——尽管与 ARM M4F/M7 内核相比是一个相当慢的 FPU。

你有没有关于你的软件与 teensy/ESP32 相结合的能力（光栅扫描速度）的任何信息？

我已经将 Teensy 4.1 驱动器推到70.000mm/min 以上，同样没有电机。我没有分析过 ESP32 驱动程序，所以我不知道它有什么功能。

我再次检查了到期日。实际上，我得到的性能是运行 grbl 的 UNO 的 5 倍左右。所以一个很大的改进。
这实际上是有道理的，因为 uno 以 16Mhz 运行，而 due 以 84Mhz 运行，这大约快 5 倍，不考虑架构变化。

我也试过使用串口，​​这个性能实际上有点差。我只能让端口在 115200 运行，所以这可能是其中的一部分。
我尝试在 /stream.h 文件中定义
“#define BAUD_RATE 500000”
，但这并没有什么不同。

也试试编程端口——我得到了很高的进给率，但我没有连接电机所以无法判断它是否断断续续。卡顿可能是由于 USB 外设开销/IRQ 优先级造成的。

高进给率是什么意思？
我在您的 SenderIO 应用程序和主动缓冲打开时达到 5200 毫米/分钟，在关闭主动缓冲时达到 3600 毫米/分钟。那就是原生 USB 端口。

使用串行端口（我不能超过 115200 波特）我只能得到 2500 毫米/分钟的进给率。
似乎慢速端口在这里受到限制。

看来我应该试试 ESP32

@terjeio有些事情让我感到困惑..

出于好奇，我greyscale_raster_test.nc从上面链接的问题中获取了文件——尝试在裸机 Teensy 和 H743 板上（均设置为最大 50,000mm/min 和 1,000mm/sec2 加速度）。我只能通过 USB 连接进行测试——正如你在另一期中所说的那样，两块板上的规划器缓冲区都不足。

但是，接收缓冲区似乎已填满（通常在任何时候都有 20-40 个字节空闲）。我无法理解的是，如果这是 USB 数据传输问题，那么接收缓冲区肯定也会被饿死吗？或者 MCU 是否有额外的开销，导致无法足够快地从接收缓冲区中取出数据的瓶颈？

（顺便说一下，我的 H743 运行时间略低于 10 分钟，Teensy4.1 运行时间略低于 20 分钟，因此 H743 端口看起来很有希望）。

@terjeio有些事情让我感到困惑..

啊不，别理我，我是个白痴 我忘了启用激光模式，所以每次功率变化时它都会停止运动！现在 Teensy 需要大约 40 秒，H743 需要大约 22 秒。

（虽然发现了 H7 端口的问题，因为它有时会在中途停顿几秒钟，将对此进行调查）。

我对光栅性能做了更多测试。我可以通过进给率和加速度的某些组合获得进给率超调 – 我猜这是由于处理器负载过高，因为我在 Teensy 驱动程序中看不到这一点。当减速发生时，规划器缓冲区就会不足（未满）。

虽然发现了 H7 端口的问题，因为它有时会在中途停顿几秒钟

延迟是否大致对应于主步进计时器的完整计数 (2^32) 所需的时间？

延迟是否大致对应于主步进计时器的完整计数 (2^32) 所需的时间？

啊哈，是的。我没有注意到，但始终是 17.89s，对应于 240MHz 的定时器时钟速率。

顺便说一句，在查找时，我注意到步进计时器不一定计算正确。我需要将 x2 乘法器的检查添加到 driver_init() – 其他 STM32 设备也可能相同..？

diff --git a/Src/driver.c b/Src/driver.c
index 9a99a99..9a4e23d 100644
--- a/Src/driver.c
+++ b/Src/driver.c
@@ -1758,13 +1758,18 @@ bool driver_init (void)
     __HAL_RCC_GPIOF_CLK_ENABLE();
     __HAL_RCC_GPIOG_CLK_ENABLE();
 
+    RCC_ClkInitTypeDef clock;
+    uint32_t latency;
+
+    HAL_RCC_GetClockConfig(&clock, &latency);
+
     hal.info = "STM32H743";
     hal.driver_version = "211211";
 #ifdef BOARD_NAME
     hal.board = BOARD_NAME;
 #endif
     hal.driver_setup = driver_setup;
-    hal.f_step_timer = HAL_RCC_GetPCLK2Freq();
+    hal.f_step_timer =  HAL_RCC_GetPCLK2Freq() * (clock.APB2CLKDivider == 0 ? 1 : 2);
     hal.rx_buffer_size = RX_BUFFER_SIZE;
     hal.delay_ms = &driver_delay;
     hal.settings_changed = settings_changed;

今天早上重新测试，将 hal.f_step_timer 设置为实际的定时器时钟频率，并且不再看到挂起 – 尽管它已将运行时间从 ~22 秒增加了一倍到 45 秒。

编辑：检查一些时间后，我可以看到运行时间的变化是有道理的，因为之前的速度是预期/报告速度的 2 倍。

在测试我即将进行的激光重建时，我在 Teensy 4.1 板上以 256 步/毫米的速度在 18000 毫米/分钟时发现了这个问题。我想达到 36000 毫米/分钟左右，但我们将在本周末将硬件放入激光机后看看情况如何。我正在使用 LightBurn 生成 G 代码，并将 LightBurn 或 ioSender 作为我的发件人。

使用光栅中的垂直框作为我的测试文件，我将它们的宽度和间距更改得更近，直到控制器似乎开始滞后。一旦我达到大约 2x2mm（宽度/间隙）的间距，电机的指令速度就会下降，并且 ioSender 报告为 17119mm/min。这也发生在 Lightburn 上，尽管我看不到进给率。一旦间距达到 1mmx1mm，速度就会下降到 12119mm/min，并且 ioSender 在没有积极缓冲的情况下开始卡顿。间距降至 0.5 毫米，进给速度降至 8569 毫米/分钟。我认识到这是 g 代码规划器的极端情况，但它是一个有趣的边缘情况。只要激光功率在减速期间表现正常，我就会认为这是一个优雅的“失败”。

当我明天有更多时间时明天进行测试的想法：
更改微步进以查看步进脉冲率是否会改变此行为。
修改计划/流缓冲区的大小
通过以太网而不是 Teensy USB 进行流式传输
将某些东西连接到主轴输出以监控“激光”功率。

@SRFirefox出于兴趣，你能分享你的测试文件吗？谢谢！

是的。这些中的每一个都设置为 18000mm/min。玩得开心！另外：更改 step/mm 设置没有任何作用。

raster_testfile.zip

您的 $0 设置是多少（步进脉冲时间）？
$0=3 并且规划器缓冲区设置为 500 步脉冲在我的示波器 @ 36000mm/m 上看起来不错。
test05x05.nc 在检查模式下于 00:18 通过 USB 传输，~200Kb/s。

提示：您可以在 ioSender 中使用文件 > 转换 > 压缩来减小文件大小。

很酷。脉冲时间可能设置为 8uS，但更重要的是我从源代码编译并忽略了将规划器缓冲区更改为高于 36 的值。我已将源代码更改为 1024 缓冲区大小并且我将脉冲时间更改为 3 时我回到硬件。也很高兴知道本机 USB 正在检查模式下爆破数据。少了一件需要担心的事情。我很想看看它在以太网模式下的表现，一些电流隔离可能会很好。

感谢您检查文件。我会在早上报告 – 我很高兴有一台更容易破解的机器！

将规划器缓冲区更改为最多 1024 个段，一切运行顺利。我的激光光栅以 48000 毫米/分钟的速度舒适地扫描，如果我小心的话，它可以加速到 60000 毫米/分钟。但这应该可以处理我能处理的所有事情，尽管我确信黑客空间的其他激光用户之一会证明我错了。到目前为止，它看起来比旧控制器更好。