@csdexter @blinkenlight: 您能否也给我提供您的前 10 个系统设置的打印输出？这也可以帮助我更快地定位到这个问题。发生这种情况时通常需要多少步？

我听到的确实是大约每秒 10 步，最后大约有 10 步，而且它似乎与进给速度无关。我刚刚用 0.7d 测试过，它做同样的事情。0.8 的设置如下：

$$
$0=400.000（x，步进/mm）
$1=400.000（y，步进/mm）
$2=400.000（z，步进/mm）
$3=30（步进脉冲，usec）
$4=200.000（默认进给，mm/分钟）
$5=1500.000（默认搜索，mm/min）
$6=28（步进端口反转掩码，int:00011100）
$7=25（步进空闲延迟，毫秒）
$8=80.000（加速度，mm/sec^2）
$9= 0.050（交界处偏差，mm）
$10=0.100（arc，mm/segment）
$11=25（n-arc correction，int）
$12=3（n-decimals，int）
$13=0（报告英寸，bool）
$14=1 （自动启动，bool）
$15=0（反转步启用，bool）
$16=0（硬限制，bool）
$17=0（归位周期，bool）
$18=0（归位方向反转掩码，int:00000000）
$19=25.000（归位进给，mm/min）
$20=250.000（归位寻道，mm/min）
$21=100（归位去抖，毫秒）
$22=1.000（归位牵引，mm）
ok

谢谢（你的）信息。当前减少此问题的解决方案是在 config.h 中增加每秒的加速滴答数。这种“停止前的额外慢步”问题因高加速度值而加剧，就像您在 80 毫米/秒 ^ 2 左右的加速度值一样。对于某些运动，快速加速会使减速曲线近似不太准确，因此您往往会注意到更多这些额外的缓慢步骤。您也可以降低加速度值作为测试。您“应该”看到理论上的差异。

我现在可以做的一件事是增加我这边的 ACCELERATION_TICKS_PER_SECOND 以帮助缓解这个问题，但要真正解决它，需要对步进器和规划器模块进行大量重写。我已经在下一个版本 v0.9 中完成了关于进给率覆盖的这项工作，所以当我到达那里时，我会确保看看我能做些什么来解决这个问题。

@blinkenlight: 如果您能够快速重新编译和重新烧写，您介意帮我一个忙吗？我有一种预感，可能是其他原因导致了这种情况的发生。您能否将 MINIMUM_STEPS_PER_MINUTE 从 800 减少到 100 或 300？看看会发生什么？它有可能在它应该达到之前达到这个限制，使其更加引人注目。谢谢！

@chamnit好的，我做了一个快速测试并使用 MINIMUM_STEPS_PER_MINUTE=100 重新编译。我不确定在运行过程中是否有什么不同（我不排除它可能已经存在），但最后额外的步骤现在大约是 ~1Hz 而不是 ~10Hz…另外，刚刚注意到一些东西- 我正在使用 Winder 的 Universal Sender 的旧版本进行流式传输，最后，我在控制台中看到了这一点（800 和 100）：

ok
ok
ok
警报：循环中止。硕士？

Grbl 0.8c [‘$’寻求帮助][‘$H’|’$X’解锁]

我不知道它以前是否存在（可能存在）- 知道这可能是什么吗？有关系吗？

好，谢谢！这排除了一件事。您是否碰巧尝试将 ACCELERATION_TICKS_PER_SECOND 增加到 100 之类的值？这应该使它更短或消失。对不起，我自己做不到。我不在家，也无法在我的机器上重现此类错误。过去，此类错误只会在某些设置中出现。

至于 Winder 的发件人，它与 v0.8c 不兼容。它必须更新以说明更改。所以发生的事情是发送方可能在完成流式传输节目后发送 Crtl-X 软重置命令。它可能做得太早了几分之一秒。每当 Grbl 在运行循环时检测到重置，它都会给你“在循环中中止”。MPos？错误。这只是意味着出现了不受控制的止损，无法保证持仓。

哎呀！使用“M2”命令进行了快速检查。只想确认一下。看起来“M2”不能正常工作会导致“循环中止”。MPos？错误。我今晚会处理它并修复它。谢谢你让我知道。:) 无论如何，这不应该导致最后的缓慢步骤。

对不起，离开了电脑。不管怎样，结果：我将 MINIMUM_STEPS_PER_MINUTE 设置回 800，并将 ACCELERATION_TICKS_PER_SECOND 设置为 100L，它似乎没有任何改变 – 我们只是回到了预期的 10Hz 步长。此外，您似乎对 M2 很了解——这确实是最后一个命令，一旦我将其注释掉，错误就消失了。

有趣的。也许这不是我想的那样。我将不得不看看发生了什么，看看是否有容易解决的问题。我猜这可能是从浮点数转换为整数时出现一些舍入错误的问题。但是，由于这不是一个严重的问题，我可能会等到我重新编写用于进给率覆盖的步进模块才能完全解决这个问题。那就是如果我不能立即找到问题。

哎呀发布在错误的问题线程中。有没有人用新的步进算法在减速结束时经历过额外的步骤？

抱歉，还没有时间对新版本做任何事情。RL 真的很烦人。我会在一两天内尝试至少玩一下它……

终于开始玩新版本（0.9 stock 可下载）——最初提到的“慢步”仍然发生在运行结束时，但它们变得更快：从假设的 ~10Hz 开始，它们似乎已经上升到大约 30Hz（现在我实际上有一个数字）。它实际上在 [1] 上非常形象地描述 – 红色、蓝色和绿色是 X、Y、Z 阶跃信号。最后一步似乎进展正常（以减速结束），但接下来是一些额外的、缓慢的步骤。知道这可能是什么吗？

[1] – http://tinypic.com/r/2ag2ewx/6

是的，我确实有任何想法，我想我昨天碰巧修复了它，但我还没有推送它。如果我是对的，只要您以三角形速度剖面而不是梯形速度剖面移动，就会出现此问题。这意味着移动没有达到标称速度。

解释如下：加速度计数器在减速时重置为总计数的一半，以遵循计算出的速度的精确减速路径。如果步进算法达到标称速度并开始从规划器计算点减速，这应该没问题，并且不应有缓慢的尾随步骤。如果步进算法直接从加速过渡到减速，则加速可能不完整并且它应该达到的速度有点偏离和较低。因此，当它开始减速时，它会过早到达目标位置。

数学上精确的解决方法是在加速-减速转换时镜像加速计数器。基本上你从当前计数倒数然后继续。通过我这个周末的测试，它似乎已经解决了这个问题。我将努力将 Timer0 禁用和此修复推送到 v0.8c master 分支。v0.9a edge 分支可能需要等待，因为它很混乱，有很多变化。

行。我在 master v0.8c 和 edge v0.9a 分支上发布了修复。可下载的固件也已更新。我希望这真的能解决这个问题。如果您有机会测试它，请告诉我。再次感谢@blinkenlight

尝试了新的 0.8 和 0.9，我很高兴地报告“最后的额外步骤”和“细脉冲”问题似乎都消失了……干得好！:)

伟大的！感谢您查看它们。多一双新鲜的眼睛来审视这些东西总是很好的。我也会关闭这个问题。