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

至于错误，维基描述如下。您说您在凸轮程序中使用了修改后的后处理器。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 代码的意图。例如，手动输入命令或流式传输某些内容。在任何一种情况下，都由用户和 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: 对不起，我应该更清楚。简单的发送并等待响应协议通过在返回错误后不再发送任何命令来正常工作。这是因为 GUI 仅在收到对发送的最后一行的确认时才发送更多命令。字符计数协议可以使存储在串行 RX 缓冲区中的命令自动执行。我想这部分需要修复，但我计划最终将其删除并在内部处理。

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

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

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

总之，这个不用担心。我正在为下一个 Grbl 项目寻找通用解决方案。为了让 Grbl 在出现 g 代码错误时停止，它需要一个额外的功能来让它不那么烦人。它在我的开发清单上已经很久了，在专业界被称为程序简历。

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

你所描述的虽然听起来很容易写入 GUI。实际上这听起来像是发出一个进给保持“！” 出错后。进给保持会停止机器，如果用户决定可以忽略错误，他们可以点击“~”循环开始/恢复，然后再次关闭。如果不是，则退出流式循环并向 GRBL 发送 rest。

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

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

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

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

==== 在串口数据接收事件中 ====
If string.contains(“error”) then <<< Checks incoming stream from GRBL for the word error
………SerialPort.Write(” !”) <<< 发送 feed hold 命令
…….BreakLoop= true <<< 设置退出 GUI 流循环的标志
…….Sleep(100) <<< Wait持续 0.1 秒以防止来自 GRBL 的警报
………SerialPort.Write(Chr(24)) <<< 发送 ctrl-X 重置命令
结束如果

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

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

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

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

流式笔记本电脑是 EeePC。现在我知道要寻找什么，我会找到一个替代方案，或者更糟的情况是自己修改 UGS

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

我不同意。字符计数可以与发送响应一样可靠。我已经在超过 100 万行长度的 gcode 文件上使用字符计数测试了我的 GUI，它运行完美。没有理由将 if 降级为仅检查模式。

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

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

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

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

至于 100 万行的 g 代码文件，下面的链接是我的保管箱中的文件。它是一个较短的 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 可以在检测到错误后，简单地停止发送响应或字符计数协议中的流，结果相同，计划程序缓冲区移动仍会运行到出现错误的行.

多谢你们。现在开始实施 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 必须做的事情。