进行以下更改也可以解决此问题。
#ifndef ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
for (idx=0; idx<N_AXIS; idx++)
{
st_prep_block->steps[idx] = pl_block->steps[idx] << 1;
}
st_prep_block->step_event_count = pl_block->step_event_count << 1;

@usbcnc：我只会做一个以上的检查来计算st.counter_x = st.counter_y = st.counter_z = (st.exec_block->step_event_count >> 1);。如果为 1，则设置为st.counter_x = st.counter_y = st.counter_z = 1;。

@usbcnc： 没关系。这打破了 Bresenham 算法。你的方法没问题。

谢谢所有人，我已经更改了我的代码 -> 如果未启用 ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING 并且 GRBL 发布到 ARM（定时器预分频器是 16 位），丢失的步骤已经解决。现在，AMASS Vs Not AMASS。什么是更好的 ？

@usbcnc：我又看了 Bresenham 算法一些。你是对的，这里有一个错误。不确定它是何时添加的。我认为这是自 v0.9 发布或更早版本以来。然而，它在正常情况下不应该发生，这可能是它从未被报道过的原因。只有当你移动得非常慢，加速度非常低，并且 AMASS 被禁用时，它可能会锁定。如果启用 AMASS，它应该更罕见或不可能，因为 step_event_count 已经扩大。

我需要仔细看看步进数据是如何处理的，如果将 step[idx] 值加倍会破坏其他东西。我确实同意这样做的正确方法，但您不需要将 step_event_count 加倍。除法操作可以从步进 ISR 中移除。

无论如何，很好的收获。仅供参考，禁用 AMASS 将不再是 ARM 版本的选项，因为有更高分辨率的计时器可用。

@chamnit，就我而言，我并没有做得非常慢。只有一步的片段才会显示问题。
我禁用 AMASS 的原因是我正在实验恒定加速度和 S 曲线，暂时我需要禁用 AMASS，我认为恒定加速度可以与 AMASS 共存，另外我正在试验“完美”弧GRBL，这些是我喜欢尝试的功能。
发现有时程序永远不会回到 0 离开几步。通过仔细分析我发送到的 g 代码和代码路径最终导致发现这个问题。
顺便说一句，我使用 Windows 模拟来解决这个问题。
我不是 arduino 人，我总是在 STM32F103 板上运行 GRBL。也许我会在某个时候想到 STM32F4，因为我发现了 STM32F4 的一些好的特性。

@usbcnc: 我没有说没有问题或我不会修复它。我说这个问题从来没有提过，因为应该是极少的。主要是因为默认情况下启用了 AMASS，并且由于 AMASS 的工作方式，这个错误在很大程度上没有浮出水面。

我检查了步进器代码，改变步数和 step_event_count 应该没有问题。以下是我要进行的更改。您可以应用这些更改并进行测试吗？对于两者，AMASS 启用和禁用，因为它确保两者都是固定的。

第 347 行：

st.counter_x = st.counter_y = st.counter_z = st.exec_block->step_event_count;

第 635 行：

for (idx=0; idx<N_AXIS; idx++) { st_prep_block->steps[idx] = (pl_block->steps[idx] << 1); }

第 641 行：

for (idx=0; idx<N_AXIS; idx++) { st_prep_block->steps[idx] = (pl_block->steps[idx] << (MAX_AMASS_LEVEL+1)); }

@usbcnc: 哎呀。犯了一个错误。您最初提出的更改应该是正确的。只需进行此更改以确保 AMASS 也应用此修复程序。

第 641-642 行：

for (idx=0; idx<N_AXIS; idx++) { st_prep_block->steps[idx] = (pl_block->steps[idx] << (MAX_AMASS_LEVEL+1)); }
st_prep_block->step_event_count = pl_block->step_event_count << (MAX_AMASS_LEVEL+1);

@chamnit. 禁用 AMASS 时存在初始错误。与进给速度或加速度无关。

要更改第 641-642 行，它适用于启用 AMASS。（我们需要这样做吗？它已经按比例放大了）。

我
对 (idx=0; idx<N_AXIS; idx++) { st_prep_block->steps[idx] = pl_block->steps[idx] << 1;的更改 }
st_prep_block->step_event_count = pl_block->step_event_count << 1;
效果很好。

但是我修改了这些行并且仍然有效，我更喜欢这些行。你怎么看？
（它们适用于（ AMASS启用与否
）
。 exec_block->step_event_count) {

原始代码是
if (st.counter_x > st.exec_block->step_event_count)
if (st.counter_y > st.exec_block->step_event_count)
if (st.counter_z > st.exec_block->step_event_count)

counter_ 值从 1 到 st.exec_block->step_event_count。
现在它的值变成了从0到st.exec_block->step_event_count -1。

在某些情况下它肯定会改变步骤，但我倾向于相信带有 = 的步骤是另一种选择。你怎么认为？

@usbcnc: 现在想想。你是对的。它与进给或加速没有任何关系。仅当 g 代码块命令仅移动一步且禁用 AMASS 时才会发生这种情况，这仅适用于需要移动速度低于 1 毫米/分钟的机器。所以，这比我原先想象的还要罕见。我将其归类为非问题并关闭它。

我仍然会在禁用 AMASS 的情况下应用您的修复程序。启用 AMASS 后，我将进行编译时检查而不是修复，以防止 AMASS 级别为零。当它为零时，它会出现同样的问题。