是的。实际上，您不应该期望在 >>jog<< 期间处理任何命令。Jog 是一种特殊情况，其中许多模态也不适用。在程序中间慢跑实际上没有多大意义，您应该使用 G0/G1 进行运动。

对不起，我说错了。当我们将程序流式传输到 GRBL 时，它使用 G0/G1 命令进行移动。

这是一个典型的程序：

设置模态 -> 立即处理
G0 到退回 -> 立即处理
G0 到第一个编程点 -> 立即处理
打开主轴 -> 直到前一个 G0 完成后才处理（机器完成移动）

之后的其他步骤具有相同的行为。

我们已切换到缓冲区计数，这已解决了我们这边的问题。

我本以为那是理想的行为——以中速打开主轴似乎有点粗略……同意，应该没关系……但是……

GRBL 是否恰好处于激光模式？

作用于当前正在执行的命令的更下游的 M 代码将非常糟糕。

考虑一台激光机——在不在适当位置时打开激光会导致在不应该切割的地方切割，从而破坏工作；或者过早地关闭它，结果是最后的几个动作不会被削减。

或者，考虑关闭冷却剂或主轴的命令 – 如果立即执行这些命令，您将要么干切削，要么在工件不旋转时将刀具推入工件。

GRBL 控制器中的命令被缓冲，并按照先入先出的原则执行。
唯一可用的其他方法是使用高级命令、暂停、重置、门等，这些命令会立即并出于显而易见的原因采取行动。
M＆G代码是工作的一部分，而不是高级命令。您正在寻找的是应该由您的后处理器处理的命令/操作。它可能出现在工业机器上，主轴在移动过程中启动，但在很可能的情况下，主轴启动然后执行移动，这会给人一种错觉，即主轴在移动时启动，因为它的初始惯性不允许它在移动开始之前加速旋转。
编写 GUI 已经够难了，而且不会陷入繁琐的位，相信 Grbl 写得很好并遵循 gcode 标准，从长远来看，它会让生活变得更轻松，我试图与系统作斗争，这里的男人和女孩不会不要让步。代码是可靠的，但只有在不乱用的情况下它才会保持稳定。

我们已切换到缓冲区计数，这已解决了我们这边的问题。

这也没有任何意义。

按照设计，M 命令在前一个 G 完成之前不会发生。它们是 Modal 的“M”……在命令完成之前更改模式会产生如上所述的各种丑陋效果。gcode 不是一种复杂的语言，在这种情况下，像这样的提升命令实际上是不可能的——你希望它们提前多长时间重新排序？由于已知的副作用，在许多情况下，这可以通过计算机代码来完成。在这种情况下，效果实际上是不可知的。如果代码生成器可以安全地更早地移动命令，它应该已经这样做了。

关于“不会让步”——只是没有太多的让步能力——代码空间很小（而且很满），代码成熟，不简单，并且涉及实时运动。我不知道您要求什么，但我知道 1.1 中的更改需要很长时间才能完成，据我所知，后续代码库的工作正在进行中。它来了，只是非常缓慢。