@109JB: 有趣的是，我只是在线下与某人讨论这个问题。你说得对，缓冲数据在错误发生后仍会执行。也许作为权宜之计，我应该强制 Grbl 进入暂停状态并等待用户交互，但这对于习惯于忽略诸如 M6 命令之类的错误的人来说可能会很烦人。这会将命令保留在缓冲区中，因此 GUI 不必重新发送它。

对于强制暂停，您基本上有两个选择：重置或继续。我想为这个事件提供一个清晰的串行缓冲区命令会很好。所以你可以有第三种选择：重新发送更正的命令并继续流。

但是，我确实建议您让您的 GUI 定期检查 g 代码程序，方法是在它预先处于 $C 检查模式时将其流式传输到 Grbl。这将帮助您事先识别潜在问题并防止此问题发生。

我是否正确认为这不应该影响发送/响应流？我认为不会，因为一次只发送一个命令，等待 GRBL 响应。据我了解 GRBL 的内部工作原理，它会接收命令并对其进行解析，在将其放入规划器缓冲区之前检查错误并发送“ok”或“error”响应。由于 GUI 在发送另一个命令之前正在等待某种响应，因此它会在那里被捕获，因此在发送/响应中不会有问题。只有有效的命令才会发送到规划器缓冲区。正确的？

使用 $C 检查是我计划在我的 GUI 中自动化的事情。只是还没有。

至于如何从 GRBL 的角度处理它，强制暂停对于 MDI 输入来说也很烦人，必须重新设置或恢复才能修复 MDI 中的拼写错误。我实际上设置了 GUI，以便我可以随意选择发送/响应或字符计数协议。现在我想我只会使用发送/响应。我做了一些测试，除了有大量非常小的动作的程序外，字符计数并没有真正的好处。例外情况是当我在我的旧 win 98 机器上进行测试时，字符计数似乎有助于 GUI 跟上。

我想我的建议是，如果发送/响应不受此影响（我认为不会），我将不理会它。我认为大多数 GUI 只是使用发送/响应。如果您确实决定在制定出更永久的解决方案之前加入临时保留功能，我会要求您这样做，以便用户有一个编译时间设置来打开或关闭它。

感谢您为 GRBL 所做的所有辛勤工作。我非常感谢你的努力，以及之前那些人的努力！！！

@109JB： 正确的。这个问题不会影响“发送-响应”简单协议。您只是无法尽可能快地进行流式传输。实际上，“发送-响应”足够快，尤其是当您将波特率更改为 250000 时。

我不打算很快安装强制暂停，如果我这样做，我会将其配置为可配置以避免惹恼暴徒。我将在界面 wiki 中将其记为已知问题。在某一点。

有一次我在响应结束时在缓冲区中添加了一些字节，所以我总是知道发送多少字节是安全的

@langwadt
这是否与正在讨论的问题有关，因为我看不出它有什么关系？

编辑-我想我现在明白了。我认为您指的是您用来简化流媒体实施的固件模块。我们所说的是 GRBL 在遇到错误后仍会执行缓冲区中的命令，这可能会导致崩溃。

@109JB：我在接下来的几周内有一些休息时间，并计划解决大量的开发积压问题并推动事情向前发展。FWIW，我正在考虑重构通信协议来解决这个问题。以及能够接受更多的实时命令来覆盖之类的东西。

我同意让 Grbl 缓冲错误。我目前正在开发的 GUI 剥离了未实现的 Grbl GCode 以在本地处理它们，因此这种错误机制对我来说很有效。