@milesingrams：这是 feed hold 的预期行为。它使系统处于挂起状态。所以有时你不会有好的反应。您可以通过监视“？”中的机器状态来了解 Grbl 何时收到保持命令。状态报告。

@milesingrams: 考虑之后，我会在 Grbl 的下一个主要版本中为实时命令添加一个简短的确认消息，例如 feed hold 和 resume，因为会有更新的通信协议。它可能会保持当前 Grbl 保持所有当前 GUI 兼容的方式。

谢谢！如果能够在无需轮询的情况下注册实时命令的接收，那就太棒了。但我能理解为什么他们没有被包括在内，因为这是一个暂停行动。
此外，您是否考虑过为 GUI 添加工作完成确认响应选项？例如，我让 GRBL 与 Z 轴末端的自动流体采样器一起运行。为了进入下一步，我必须确保平台和流体采样器都已完成所有排队的操作。目前我通过轮询阶段的状态并等待它说“IDLE”来做到这一点，但是当所有缓冲的移动完成时，让 GRBL 自动发送“Job Done”状态的选项可能会很好。

@milesingrams：强制 Grbl 清空其队列的最简单方法是向其发送 G4 驻留命令。当您收到对此的“确定”时，您将知道它已完成。M2/30 程序处理可能也应该以这种方式运行，但现在不是。我在考虑要不要强行暂停一下。

Grbl 也无法判断作业何时完成，因为它正在以片段的形式流式传输程序。

这绝对是一个需要知道的妙招。但是，就我而言，我只想确切地知道舞台何时到达所需位置。例如，如果我发送 G0 命令告诉舞台转到 X100 Y100，我会收到命令已处理的“确定”，但不会告诉我舞台位于 X100 Y100。为了知道我需要用“？”进行轮询 并等待空闲。由于轮询实际上被限制为 5Hz，所以在我知道移动已经完成之前我可能会损失 200ms。

@milesingrams：我的意思是，如果您在 G0 X100 Y100 之后发送 G4 驻留命令，当您从 G4 命令收到“确定”时，您就会知道移动已经完成。

啊啊啊。知道了。这非常有用。我会试一试。谢谢！