问题不在于 GRBL。坦率地说，这是您用来发送到 GRBL 的程序。一旦 GRBL 发送错误响应，接口应立即暂停 GRBL，停止发送 G 代码行，然后重置 GRBL，这将清除规划缓冲区中的任何内容。

至于错误，维基描述如下。您说您在 cam 程序中使用了修改后的后处理器。I 和 J 值可能在 G90.1 绝对坐标中。GRBL 不支持。I 和 J 必须是 G91.1 增量值。用我的计算器在第一个弧线上快速检查确认这是正在发生的事情。

33：运动指令的目标无效。G2、G3 和 G38.2 会产生此错误。对于使用半径定义的探测和跟踪的圆弧，当前位置不能与目标相同。当弧在数学上不可能追踪时，这也会出错，其中当前位置、目标位置和弧的半径没有定义有效的弧。

@109JB谢谢回复。可能也需要在这里反馈给 UGS 的人。我期待停止就像达到极限一样。如果没有及时清空planner buffer，GRBL仍然会进行。

至于凸轮后处理器，我没有改变任何重要的东西（我不够专业，无法确保它不会破坏任何东西）。我只是删除了对一些 GRBL 不支持的 G 代码的支持，因此使用另一种内置方法来生成正确的 G 代码。

仅当我将工件旋转 5 度以适合我的工件时，才会出现此问题。我又直接剪了一次，剪得很好。

@faultylee: Grbl 的流式协议无法区分 g-code 的意图是什么。例如，手动输入命令或流式传输某些内容。无论哪种情况，都由用户和 GUI 决定在 g 代码中遇到错误时该怎么做。Grbl 有可能在出现错误时自动停止一切，但这会大大降低它的可用性（并惹恼大量用户）。

最简单的做法是在 GRbl 返回错误时让 GUI 停止流式传输。即使 Grbl 的运动规划器中有运动排队，这些运动都是有效的，机器将在流停止的点停止。

@chamnit
我要么误解，要么不同意这种说法：

“最简单的做法是在 GRbl 返回错误时让 GUI 停止流式传输。即使 Grbl 的运动规划器中有运动排队，这些运动都是有效的，机器将在流停止的点停止。”

必须做的不仅仅是停止流媒体，否则可能会发生灾难性的后果。例如，我经常手工编写代码。假设我输入了一个具有以下代码块的 g 代码程序：

=== 一些以前的 G 代码在 Z= -1 英寸处有 Z ===
N011G90G0Z1 <<< 将 Z 提高到零件上方 1 英寸以清除我的虎钳
N012 G0X5 <<< 快速到我零件的另一端
===这里有更多代码=====

但是我打错了代码，结果是这样的：

===这里有一些以前的G代码，Z=-1英寸===
N011G900Z1 <<<缺少第二个“G”击键
N012 G0X5 <<<快速到我的部分的另一端
===更多代码这里=====

这将是一个非常简单的错误。如果您只是停止流式传输，将会在 N011 处引发错误，但 GUI 已经发送 N012 并且它位于 GRBL 规划器缓冲区中。将会发生的情况是会抛出错误，但不会由于错误而发生移动到 Z=1 的净高。然后，将使用低于安全高度的工具运行 N012 线并将其撞到我的虎钳上。因此，在这种情况下，只是停止流式传输的 GUI 仍然会让机器撞到我的虎钳上。

需要做的是尽快停止运动，停止从 GUI 流式传输，并清除 GRBL 缓冲区。我在我的 GUI 中所做的如下：

1 – GRBL 报告错误并由 GUI 接收
2 – GUI 立即发出“！” 保持停止机器运动的命令。这是自“！”以来我能找到的最快的停止运动的方法。从流中挑选出来并由 GRBL 立即解释。
3 – GUI 退出流循环以停止传输任何更多行 G 代码
4 – GUI 发出 ctrl-X 命令以重置 GRBL，从而清除计划器和接收缓冲区。

确实，我的解析例程实际上会捕获上述错误，甚至从未将其发送到 GRBL，但如果我在解析器中遗漏或未考虑某些错误情况，我仍然启用上述错误。上述步骤可能不是唯一的方法，但在我看来，必须立即停止运动并阻止所有进一步的运动，无论是来自 GUI 发送更多命令，还是来自 GRBL 中已有的命令缓冲区。

可能应该区分错误，或者更确切地说是致命错误，例如软/硬限制。有些错误可以安全地忽略，有些则不能。当我第一次打开软限位时，我一开始面临可用性问题，机器停机，我仍然需要找出导致它的原因，最终学会正确放置工件并正确设置限位。我看不出如何忽略作为完整 Gcode 一部分的弧。

我认为这里与其他潜在的灾难性错误相同，起初它会引入可用性问题，因为用户必须找出问题所在，但最终我们将学会纠正我们的错误（在我的情况下是 CAM 软件）和可用性将不再是问题。我宁愿安全而不是抱歉。

可能对于那些可以安全忽略的 Gcode，可以将其响应为“警告”，以便与应该停止的致命/错误区分开来。我没有在这里和 shapeoko 论坛上进行所有讨论，但我敢打赌围绕这个问题进行了辩论。我确实看到了一些关于 GRBL 与 GUI 应该处理的事情的争论。

只是我的诚实反馈，对你们投入 GRBL 的出色工作和时间没有冒犯

任何当前已知的可以正确处理错误或至少用户可以选择停止的 GUI？

@faultylee
我不同意存在可以忽略的任何 G 代码错误的前提。没有办法知道 g 代码是否具有潜在的灾难性。每个 G 代码错误都应该被视为灾难性的。

底线是 GRBL 中没有任何东西需要更改。简单明了，GUI 必须处理错误。

至于正确处理错误的 ag GUI，我相信我的。您可以通过以下链接下载来试用它。

https://dl.orangedox.com/EqqZYCIOLOeHIrjLc6/109JBs%20GRBL%20Interface.zip

如果您决定尝试它，请在提问之前阅读我整理的手册，并且不要在这里提问。这个地方适用于 GRBL，而不是我的 GUI。如果在阅读手册后您有任何疑问，您可以使用程序帮助下拉菜单中的链接给我发电子邮件。

@109JB: 对不起，我应该更清楚。简单的 send-and-wait-for-response 协议可以正常工作，因为在返回错误后不再发送任何命令。这是因为 GUI 仅在收到对发送的最后一行的确认时才发送更多命令。字符计数协议可以使存储在串行 RX 缓冲区中的命令自动执行。我想这部分需要修复，但我计划最终消除它并在内部处理它。

@faultylee：@109JB声明所有 g 代码错误必须停止是正确的。这是因为 g 代码是高度模态的，如果遗漏了一个，整个程序就会受到影响。我相信 bCNC 也有错误处理的选项。

也就是说，Grbl 还有一个检查 g 代码模式，由$C命令调用。你可以流式传输整个程序，Grbl 会像往常一样解析它，但不会移动任何东西。它是用户和 GUI 在运行作业之前检查错误的一种方式。

至于错误状态，Grbl 已经有一个致命错误。这是Grbl的闹钟模式。当事情变得非常糟糕时使用它。

无论如何，不​​要担心这个。我正在为下一个 Grbl 项目制定通用解决方案。为了让 Grbl 在 g 代码错误时停止，它需要一个额外的功能来使它不会令人讨厌。它在我的开发清单上已经很久了，在专业界被称为程序简历。

@chamnit
我个人认为，从用户的角度来看，GRBL 中的任何自动错误检测 – 停止都会很烦人。例如，在 MDI 窗口中输入错误会触发暂停，这需要用户交互才能重新发出更正的 MDI 命令，这对我来说很烦人。

您所描述的内容听起来可以很容易地写入 GUI。实际上这听起来就像只是发出一个提要保持“！” 出错后。进给暂停将停止机器，如果用户决定可以忽略错误，他们可以点击“~”循环开始/恢复，然后再次关闭。如果没有，则退出流循环并将休息发送到 GRBL。

即使在 GRBL 中实现，仍必须正确编写 GUI。假设 GUI 正在流式传输 G 代码文件，而 GRBL 检测到错误并停止。要停止流式传输，GUI 作者仍然必须退出流式循环，否则一旦收到另一个 ok 响应，它将再次启动流式传输。

我认为处理错误响应的正确位置是在 GUI 中。这很容易，GUI 作者需要加强并正确处理错误。在我的 GUI 中，它的核心仅由 9 行额外的代码处理。GUI 作者真的没有借口不把它放在那里。

这是我的代码中的重要行（Visual Basic）

========定义全局变量以用作循环退出的标志 =======
Public BreakLoop as Boolean = False

==== 在串口数据接收事件中 ====
If string.contains(“error”) then <<< 检查来自 GRBL 的输入流中是否有 error
……..SerialPort.Write(” !”) <<< 发送 feed hold 命令
……..BreakLoop= true <<< 设置退出 GUI 流循环的标志
……..Sleep(100) <<< Wait 0.1 秒以防止来自 GRBL 的警报
……..SerialPort.Write(Chr(24)) <<< 发送 ctrl-X 重置命令
end if

====== 在 GUI 的流循环中 =============
BreakLoop = False <<< 初始化此变量，以便循环不会立即退出
（流循环开始）< << 现有的流式循环。
……..（此处的其他命令）
……..如果 BreakLoop = True then Exit For <<< if 停止进一步流式传输的语句
……..（此处的其他命令)
( 流循环结束)

@109JB谢谢，太糟糕了，我在主笔记本电脑和将 gcode 流式传输到 GRBL 的笔记本电脑上都运行 Linux。难怪我之前没有注意到你的申请。

@chamnit$C 现在有意义了，所以我会配合到我的 CNC 工作流程中，再次感谢。

如果它具有 USB 访问权限，您可能可以在虚拟机中运行它。

流媒体笔记本电脑是 EeePC。既然我知道要寻找什么，我会找到替代方案，或者更糟糕的情况是自己修改 UGS

您好，
我认为在 gcode 文件上要做的第一项工作是使其与 Grbl 完全兼容。
然后可以处理传输错误。
简单的“呼叫-响应”协议似乎是传输 gcode 文件最可靠的协议。
字符计数协议应仅用于模式“检查”。

我不同意。字符计数可以与发送响应一样强大。我已经测试了我的 GUI，它对长度超过 100 万行的 gcode 文件进行了字符计数，并且它的性能完美无缺。没有理由将 if 降级为仅检查模式。

至于错误检查，是的，用户应该尝试确保代码是好的，但是当 grbl 抛出错误时，GUI 不应该忽略它。

@109JB： 我认为@LETARTARE表示字符计数协议有一些与之相关的*规定。这意味着您无法控制串行 RX 缓冲区中的内容。如果 Grbl 抛出错误，即使您停止了流式传输，Grbl 仍将解析并执行其中的内容。发送响应协议并非如此。因此，最好在通过字符计数协议将 g 代码流式传输到 Grbl 之前检查 g 代码是否存在错误。

@109JB:
我交替使用这两种协议。因此，“呼叫响应”协议在编程方面更容易编写更健壮。
我对超过 100 万行的代码感兴趣：我能得到它吗？
其次，我建议定义一个兼容的文件扩展名 Grbl ，例如：’grnc’ 或其他，以区分更容易兼容的 Grbl 其他文件。

@LETARTARE– 我想我们对“健壮”有不同的定义。我从“更健壮”的程序的角度来看待它，它发生错误的可能性较小，或者可以比“不太健壮”的程序更好地处理这些错误。从这个意义上说，正确实现的字符计数协议和发送响应协议之间没有区别。在这个定义下，一个可以像另一个一样健壮。虽然发送-响应协议确实更容易为其编写代码，但它本身并不能使其更健壮。根据我的发送响应协议的稳健性定义，我会判断我的字符计数协议是相等的。

至于 100 万行的 g-code 文件，下面的链接是我的 Dropbox 中的文件。它是一个较短的 g 代码文件，粘贴次数与获得超过 100 万行所需的次数一样多。我认为它开始时有 40,000 行左右。

https://www.dropbox.com/s/etq8tdtpaszlzd1/1-million%20line%20file.nc?dl=0

@chamnit– 您所说的在字符计数端口期间无法控制 RX 缓冲区中的内容是正确的，但并非完全如此。如果您只是停止流式传输，则将执行 RX 缓冲区中剩余的命令。我想这就是您无法控制的意思，但这就是为什么我说 GUI 不能只是停止流式传输。保持、流停止和重置，按此顺序快速停止运动并刷新所有延迟命令的计划程序和 RX 缓冲区，因此可以对 GRBL 缓冲区中的内容（包括 RX 缓冲区）进行一些控制。就错误检测而言，这是 GUI 真正需要的所有控制。

在我看来，当使用调用响应协议时，当我们看到错误响应并允许 grbl 完成所有直到错误行的所有内容时停止流式传输是最有意义的，而不是在当前移动的中途中止因为我们检测到未来的区块有错误。也许还可以自动发送命令来关闭主轴和冷却液（我还没有实现，但这似乎是个好主意）。

字符计数协议的问题更大，因为如果您在看到错误时停止流式传输，则可能会有更多的块在 grbl 的串行缓冲区中等待执行，并且除了重新启动 grbl 之外，我们没有办法刷新它们。

在我的 GUI 中，我实现了一种混合协议模式，当 grbl 处于检查模式时我使用字符计数（它大大加快了检查时间），否则使用呼叫响应。这对我来说似乎是一个很好的妥协，因为在 115200 波特时，实际切割时呼叫响应通常足够快。

@109JB:
谢谢你的文件，我会根据两个协议测试它。
定义强大的软件：
https ://en.wikipedia.org/wiki/Robustness_%28computer_science%29
@AlexHolden:
我也是这样。
@chamnit:
你认为如何定义兼容的文件扩展名 Grbl？

@LETARTARE – 请注意，我发布的 100 万行代码可能包含一些与原生 GRBL 允许的 G 代码命令不兼容的代码。我不记得我是怎么做到的。我的 GUI 支持 GRBL 本身不支持的一些东西，因此如果只是按原样流式传输到 GRBL，它可能会引发错误。

考虑一下我今晚在回家的飞机上的事情，我认为您可能正在考虑“更强大”的发送响应，因为您更喜欢简单地停止流式传输以进行错误检测的方式。我从“字符计数是否更容易在 G 代码运行期间使 GUI 崩溃”这一点考虑它？从这个角度来看，它不是，至少不是我实现它的方式。我认为任何一种看待它的方式都符合“稳健”的定义，只需要弄清楚每个人的来源。

@AlexHolden虽然我同意发送响应在大多数情况下是相当充分的，但在某些情况下字符计数会带来好处。一个例子是在运行 CAM 中创建的 3D 加工操作时运行高进给率。这些操作通常包括非常短的动作，并在程序中一遍又一遍地重复。我在我的机器上做了很多这方面的测试，发现虽然运行时间的好处不是很大，但有一些，但最大的好处显然是机器运行更流畅。在我的一个测试程序中，创建一堆这些短动作的功能将导致使用发送响应导致 GRBL 的规划器缓冲区饥饿，从而导致由于缺乏前瞻和较慢的计算机而导致明显的“抖动”动作，甚至让 GRBL 空闲一段时间，因为它正在等待数据。我可以在我的 GUI 上的状态监控中看到这一点。在同一个 CAM 生成的文件上使用字符计数协议会缩短周期时间，但最大的好处显然是在有很多短动作的部分中操作更顺畅。字符计数允许 GUI 赶上移动时间较长的部分，结果是 GRBL 不会空闲，实际上维护了一个至少 1/2 满的计划缓冲区，通常在计划缓冲区中有 16 或 17 个命令. 当然，由于我实施了固定循环、工具更改等，我的 GUI 不仅仅是从文件中获取命令并将它们发送到 GRBL 之外，还有很多事情要做。具有简单流式传输方案的 GUI 可能不会像我的那样注意到这些效果。无论如何，我将其留给用户他们想要使用的协议，因为它可以在我的“用户设置”窗口中选择。

至于错误检测和发送响应与字符计数，我同意简单地在发送响应中停止流式传输就可以了。我想我实际上会在我的 GUI 中更改它。在字符计数方面，我认为在第一次出现错误指示时停止并不重要，即使规划器中还有命令。我这样说是因为如果出现错误，无论程序在哪里停止，用户都必须纠正错误并重新运行 G 代码。字符计数协议的好处可能会超过这个小损失，但可能是用户应该能够决定的事情。

@chamnit这个讨论（我认为一个非常好的讨论）提出了可以在 GRBL 错误检测方面完成的一件事，那就是简单地让 GRBL 在遇到错误时仅刷新 RX 缓冲区，或者提供一种方法GUI 作者可以刷新该缓冲区。如果发生这种情况，那么 GUI 可以在检测到错误后，简单地停止在 send -response 或字符计数协议中的流式传输，结果相同，规划器缓冲区移动仍将运行到出现错误的行.

多谢你们。现在开始着手实施 G90.1。

@109JB: 也不确定这是否是正确的解决方案。如果您自动刷新 RX 缓冲区，则 GUI 必须确切地知道它需要重新发送什么，要么通过 GUI 正确跟踪回复，要么通过 Grbl 回复一条特殊消息，通知哪条线路有问题。对于后者，这将需要进一步对协议进行一些修改，例如将接收到的行值附加到每个 ok 或 error 语句。

不确定我现在是否想进入那个兔子洞，但我认为最终将需要这样做。

@LETARTARE: Grbl 没有文件扩展名的理由，因为它没有文件依赖关系。您只需将 g 代码流式传输到它。它是管理文件的 GUI。

@chamnit
如果我错了，请纠正我，但如果 GRBL 检测到错误，则保留在 RX 缓冲区中的所有命令都是错误行后面的命令。正确的？

这可能只是我的意见，但是一旦遇到错误，流应该停止在（或之前）出现错误的那一行。GUI 可以停止发送，如果 GRBL 刷新了 RX 缓冲区，则会处理 GUI 已经发送的错误之后的行。

@109JB： 你是绝对正确的。但是就像我之前说的，GUI 需要知道它需要在哪里重新发送，因为 RX 缓冲区中的内容可能会提前几个块。GUI 需要跟踪它，我想尽可能多地从 GUI 必须做的事情中卸载。