在 v0.9 中，新的步进算法应自动处理方向引脚问题。它（应该）总是在任何步进事件发生之前至少将方向引脚设置为一个恒定的计时器滴答。对于 30kHz 定时器滴答，这是 33.3 微秒。这是硬编码的，不幸的是无法更改。尽管如果您需要更大的延迟，将定时器滴答频率降低到 20kHz 之类的频率将有效地尝试隔离和识别此问题。这会将方向引脚延迟增加到 50 微秒，但您将被限制在 20kHz 的最大步进速率（建议 15kHz 或更低）。

至于漂移问题，自发布以来我还没有对 v0.9 进行过非常彻底的测试。我非常关心这件事，所以请尽可能多地发布您所知道的关于它何时或如何发生的信息。我确实知道 feed hold 和 v0.9 存在问题，可能会导致这种情况，但我没有真正的时间来处理 grbl 并推动修复。然而，在发生的一连串事情终于结束之后，我将在下个月骑上 grbl 马。

我在test.gcode的第 2416 行看到一些奇怪的问题

注意到一些故障，机器会发出沉闷的声音，并且看起来（真的很快）轴在快速连续执行下一个命令之前瞬间反转方向。

还注意到计划程序缓冲区似乎正在挨饿，因为每几次传递都有 1 秒左右的暂停。

仍然在我的机器上漂移，虽然在下降到 20khz 之后它似乎有所改善：

• 在 20khz 变化之前：在 gcode 文件中的特定点漂移 ~15mm
• 更改后：在相似点漂移 ~5mm

这是我的机器当前的设置。

有可能我一直在尝试的 CAM 生成了一些奇怪的 gcode，使 grbl 进入了一个奇怪的状态，但我已经通过一个自定义的“gcode cleaner”运行它，它应该已经删除了所有奇怪的位。我会继续摆弄东西，但任何漂移毫米尺寸似乎都是某个地方的主要问题。

看起来没什么异常，但看起来像是 CPU 限制。首次安装 arcs 时，我们遇到过此类问题。CPU 实在是太慢了，跟不上，不断地耗尽缓冲区。通过降低计时器滴答率和所有条件都相同，这似乎证实了这个问题。您可以进一步将计时器滴答率降低到 10kHz 甚至降低到 5kHz，因为您的机器不能超过 1kHz 的步进率。希望这可以解决您的问题。

我一直在采取一些措施来提高规划器的核心效率，但很难说它是否会对您的机器产生足够明显的影响，让这个问题消失。（进给率覆盖代码将抵消这些改进，因为它也需要大量开销。）我还采取了更多步骤来保护规划器，以在缓冲区完全耗尽但仍准确执行移动的情况下进行覆盖保护. 就像我之前在其他地方说过的那样，我将在 7 月中旬回到开发模式，届时事情终于平静下来，空闲时间又回来了。

所以我的问题似乎是双重的

1. 当我构建新的 cnc 时，我使用了更大的步进器/驱动器。显然我们忘记连接启用引脚。修复大大减少了我因测试削减而造成的浪费；）
2. config.h 更改修复了暂停问题：

• ISR_TICKS_PER_SECOND=10000L
• RANADE_MULTIPLIER=1000000.0
• ACCELERATION_TICKS_PER_SECOND=200L

在 ISR 上远低于 10k 似乎没有时间加速，这会导致步进器丢失大部分步数。我确信其中一些值可能太高/太低，但它在我的机器上似乎运行良好。

现在有趣的是，我不知道它在 0.8 之前是如何工作的。我想驱动器上的启用端口可能在过去的某个时间点供电，但在我尝试隔离问题或移动东西时，它们被分离/移除了。

再次感谢@chamnit你总是那么乐于助人?

@tmpvar: 有趣的结果。感谢您的报告。

我担心您无法进一步降低 isr 频率的问题。您是否尝试过增加每秒的加速度滴答数？我认为您可以将此值增加到 isr 频率，但可能存在一些舍入误差。我认为当你降低 isr 频率时，你可以相应地增加每秒的加速度滴答声。如果不是这种情况，则代码中有问题。有机会我会去看看的。

至于 v0.8，步进算法对于您的机器类型可能更有效，即非常低的频率。V0.9 旨在解决频率高于 10kHz 的问题。你的机器也应该没问题，但是当你以高进给率和短线段运行时，我想步进算法增加的开销可能是一个不幸的权衡。我肯定需要重新考虑 v1.0 的一些事情，看看我是否可以进一步提高性能或自动适应给定用户机器设置的最佳 isr 频率。