@embededhell：是的，这是 Grbl v0.9i 中的一个错误。Grbl 在 M0 暂停和 M2/30 程序结束时进入暂停状态，很像提要暂停，但报告它是空闲的。要退出，只需向 Grbl 发送一个“~”恢复命令，它就会继续。

我一直在尝试想一种方法，让 GUI 和用户更清楚地了解这种行为正在发生的事情，而不需要为所有 GUI 引入新的东西来支持。

• 对于 M0 程序暂停，我可以让 Grbl 进入“HOLD”状态。这很容易。它应该是兼容的 GUI。
• 对于 M2/30 程序结束，这有点棘手。当发布 M2/30 时，机器控制器必须根据其定义进行重置（Grbl 软重置），但 Grbl 必须阻止来自 GUI 的任何流数据。您不能允许在 M2/30 之后执行任何 g 代码。因此，停止流式传输数据并重置 Grbl 真的取决于 GUI。我可以让 Grbl 报告“HOLD”状态，就像 M0 一样，但这并不能告诉 GUI 为什么它处于保持状态。也许，我需要做的就是发回一条反馈消息，比如[Pgm End]让 GUI 知道发生了什么，并且它需要发送一个“~”或一个Crtl-X来手动重置 Grbl。

我仍在尝试找出最好的方法是什么，我欢迎任何想法。

@chamnit: 非常感谢您的回复。

我远没有资格提出任何严肃的建议，我对整个 Gcode 事物的理解仅限于使用一台机器。我只能传递我的观察。

发送一个’‘ 通过串行终端可以正常工作。
通过 Universal Gcode Sender 发送相同的内容不起作用。我假设它在 M2/M30 之后等待 Grbl 重置和缓冲命令。
添加’‘ 到程序结束，在 M30 产生相同的结果之后。据 Gcode Sender 所知，程序永远不会完成。

@embededhell：我记得也有这个问题。~我认为 UGS 可能会从手动命令和 g 代码程序中自动过滤掉字符。

@embededhell：尝试暂停作业并取消暂停。它可能必须更正键绑定才能继续前进。

@chamnit: 我恢复到 0.9g，这暂时解决了我的问题。一旦时间允许，我可以回去尝试暂停，但不是现在。

你好，
模式“检查”会发生什么？

@LETARTARE：它进入相同的挂起模式。接得好。我也需要解决这个问题。

为了防止 M30 问题，我确实忽略了前端软件 SerialComCNC 中的 M30 命令。对于下一个版本，M2 也将被忽略。
这样做的好处是使世界坐标轴的零点有效。如果您想在同一个工件上继续工作，这将很有帮助。

或者您可以更改 CAM 软件的后处理器，以便不在程序末尾放置 M30。当我弄清楚 M30 在做什么时，我就是这么做的。

在 GUI 中很容易选择消除 M2 或 M30 并将选择权留给用户，直到消除错误。

在我的 GUI 中，我让 GUI 拦截所有这些并在内部处理它们。如果您提前知道的话，在 GUI 中很容易做到。

如果在读取任何这些停止命令时以及在执行->软复位读取 EEPROM 值并发送“ok”之后向 EEPROM 中写入位，是否有可能？或者可能是一个完整的字节，表示换行和回车的数量，以用适量的“ok”来响应。因此，如果您使用例如 UGS 并将其设置为单命令模式，它将具有预期的行为。

@soundstorm: Grbl 应该有一个预期的行为，而不是可配置的行为。这将使 GUI 更难知道如何处理它。我一直在考虑这个问题，建议如下：

• M0 程序暂停：只需将 Grbl 置于 HOLD 状态。循环启动/恢复以继续。
• M2 程序结束：将 Grbl 置于 HOLD 状态。恢复后，它将重置控制器。
• M30 程序结束和复位：只需复位 Grbl。不要为阻止命令而烦恼。

@chamnit:
由于 GUI 等待一个（或多个带有 \r\n 的）ok，因此必须在 M2/M30 重置后发送 ok。因此，我对 EEPROM 的想法。
对于 M0，它工作正常，按下 A2 上的按钮。

GUI 不需要“确定”。对于 M0 或 M2，它被告知它处于 HOLD 状态，这足以告诉用户正在发生什么。对于 M30，没关系，因为它会自动重置。

好吧，比@winder必须将此行为添加到 UGS。不知道其他 GUI 是如何处理的，所以你可能是对的。

@chamnit, 假设所有这些都将等到协议缓冲区为空以避免在排队运动时保持/重置是正确的吗？

当从 Grbl 检测到/返回 Hold 时，GrblPanel 停止发送 gcode。Grbl 上的规划器缓冲区中可能有也可能没有 gcode，因此 Resume 将继续（在 M0 的情况下）

@ashelly：是的，计划缓冲区在执行 M0/2/30 之前被清空。我想 GUI 很难在没有某种确认的情况下判断 HOLD 是由 M0/2 还是由用户提要保持引起的。

也许我可以让 Grbl 回复一条反馈信息，比如它[PGM PAUSE]是否[PGM END]成立。根据 g 代码解析器如何执行事物的一般设计，这将是在发回“ok”之前。或者，让它在 M0/2/30 线进入暂停之前发送一个“ok”。

我在状态响应中寻找 Hold ，如果有一个 ok 与 GrblPanel 无关紧要。一旦检测到保持，我就会进入保持状态。Hold的来源应该不重要吧？

@gerritv: 没关系，但这并不意味着其他 GUI 实现以与 GrblPanel 相同的方式处理它。

@chamnit @gerritv：如前所述，如果没有 ok 返回，Universal G-Code Sender 将等待无穷大。所以反馈会很好。由于我目前正在使用 SD-Card 开发 LCD 桥接器，因此以这种方式处理状态会更容易，而不是解析发送到 Grbl 的每个命令并检查它是否是提到的其中一个。

这是我对此的看法。

M0 和 M1（在我的 GUI 中实现）是暂停命令，需要用户操作才能继续运行。有没有人真的使用命令行来运行 GRBL。我对此表示怀疑，这提供了 2 个选项：
1. GUI 拦截 M0 并在 GUI 内处理它。很容易做到，这就是我正在编写的程序的设置方式
2. GRBL 通过进入保持状态暂停。这很好，但仍然需要用户交互，这仍然需要由 GUI 处理。
选项 2 显然是这里的最佳选择，并且效果很好。对于本质上只是流接口的超简单程序，它的优点是不依赖 GUI 来执行此操作。

关于 M2/M30，我真的看不出 GRBL 需要软复位的地方。我知道 M2/M30 的逻辑是重新加载默认模态值，理论上重置是这样做的，但实际上，考虑到用户启动机器的场景，慢跑找到零部分，也许其他一些 MDI东西等，其中一些模态默认值无论如何都会更改。良好的 G 代码编程实践是在文件的开头放置一两行，以将模态值设置为程序应有的值。此外，在程序运行开始时进行软复位比结束时更合乎逻辑。通过这种方式，模态值在程序开始之前被设置为默认值，您可以确定一切都处于默认值。

至于在 M2/M30 之后防止数据进一步流式传输到 GRBL，无论如何都必须在 GUI 级别完成。如果 GUI 正在等待 OK 并且遇到 M2/M30 时 GRBL 重置，则 GUI 将获得其 OK 响应并重新启动数据流。即使 GRBL 报告类似 [pgm end] 的内容，这是一个好主意，也必须编写 GUI 以了解此响应的含义并采取相应措施。一个功能齐全的 GUI 应该已经通过在程序中看到它来知道这一点。

关于在 GRBL 状态响应消息中拦截 Hold 响应，以便 GUI 知道有一个 Hold 似乎毫无意义，我的程序没有这样做，下面是原因。正如我所看到的，暂停仅来自以下几件事：
1. 首先是用户（或 GUI）向 GRBL 发送暂停命令。这可能是一个 MDI 输入，或按下 GUI 上的 Hold 按钮。在任何一种情况下，用户或 GUI 甚至在 GRBL 之前就知道将要暂停，那么为什么要等待响应来验证已知内容呢？
2. 其次是G代码程序中的一个指令保持/暂停（M0/M1）。同样，在这种情况下，正在流式传输数据的 GUI 在发送数据之前就知道等待即将到来。等待 GRBL 的回应似乎毫无意义。

当然，GRBL 需要对暂停命令采取行动，它确实如此，但 GUI 如何知道发出暂停命令应该是从内部发出的。反正在我看来。

可以编写一个 GUI 来处理所有这些，而无需像现在一样更改 GRBL 中的任何内容。我的 GUI 在内部处理所有这些，并且可以正常工作。唯一的问题是是否应该更改 GRBL 以支持不够智能以某种方式在内部处理这些事情的 GUI。我会说应该更改 GUI，但这只是我的意见。

说了这么多，如果最终对 GRBL 进行更改，我将投票支持以下内容：

1. M0 暂停 ​​- 让 GRBL 进入暂停状态“！” 并等待恢复命令“~”
2. M2/M30 程序结束 – 让 GRBL 发送类似“pgm end”或类似的响应，让 GUI 从那里找出答案。

只是我的2美分。

约翰·B。

回复：
说了这么多，如果最终对 GRBL 进行更改，我将投票支持以下内容：

M0 暂停 ​​- 让 GRBL 进入暂停状态“！” 并等待恢复命令“~”
M2/M30 程序结束 – 让 GRBL 发送类似“pgm end”或类似的响应，让 GUI 从那里找出答案。

当 Grbl 重置时，状态会被发送回他的 GUI。GUI 应该对该状态采取行动，例如警报和内部关闭商店。UCS 似乎没有做这些事情中的一些（从前一段时间的记忆中），并且当它有时没有得到“好的”时会变得紧张。促使我自己编写的一件事（我不做 Java）

M2/30 的 linuxcnc gcode 描述仅说明机器控制器进入 MDI 模式并重置大部分 gcode 状态。因此，Grbl 需要软重置的假设是不正确的。它需要做的只是重置解析器状态。

所以这是修改后的提案：

• M0：只需设置 HOLD 状态并使用~命令恢复。
• M2/30：发送[PGM END]反馈信息，恢复机器控制默认值（可能运行 $N 启动行？），但不要软复位。在 M2/30 之后停止发送程序中任何剩余的 g 代码取决于 GUI。在这种状态下，Grbl 在技术上是 IDLE 并且仍然可以接受 MDI 命令。G92 偏移仍然有效。

好的，回滚：UGS 的行为应该如此，我的错。

让 GUI 拦截 M2/M30 允许它不再向 GRBL 发送任何数据。如果 GUI 等待 GRBL 告诉它有一个 M2/M30 事件，那就是规划器缓冲区中可能有数据的地方。

我的 GUI 可以识别任何这些命令并在内部进行操作。一旦找到 M2/M30，就不会向 GRBL 发送命令行，这意味着在 M2/M30 之后的缓冲区中没有数据需要担心。

有人评论说您可以忽略 M30/M2，这是正确的，但不是行业惯例。将 M2/M30 插入现有程序的中间以进行部分运行并不少见。例如，具有粗加工和精加工循环的程序。可以插入 M2 以仅允许粗加工操作。

GRBL 应该有一些最小的东西来捕捉 M0/M2/M30，但在我看来，如果与 GUI 一起使用，GRBL 甚至不应该真正看到它们，因为 GUI 应该首先看到它们并在那里对其进行操作。

所以，我认为最近的提议是@chamnit从 GRBL 的角度来看是完美的。这是最小的影响，可以完成工作。

@109JB: 既然你有LinuxCNC系统运行，你能帮我一个忙吗？你能检查 LinuxCNC 上 M2/30 在参数和解析器默认值方面的行为吗？我特别好奇 G92 是否在 M2/30 上重置。谢谢！

我会看看我能做什么。我的笔记本电脑上的虚拟机中也有它，所以应该不是问题。

看起来 G92 没有在 M2 或 M30 上重置。从 linuxCNC 用户手册，

“LinuxCNC 存储 G92 偏移并在下一次运行程序时重复使用它们。为了防止这种情况，可以编写 G92.1（擦除它们），或编写 G92.2（删除它们 – 它们仍然被存储） 。”

因此，除非使用 G92.1 或 G92.2 专门擦除或删除，否则 G92 将保持不变。我不确定 92.1 和 92.2 之间的区别，因为它们在功能上似乎做同样的事情。

@109JB： 谢谢！这清楚了很多。我也看到了 LinuxCNC 的描述，想知道为什么它与我的理解相反。经过一番挖掘，原来 NIST g-code 标准文件规定 G92 应该在 M2/30 时取消。Grbl 最初是为遵循 NIST 而编写的，而不是 LinuxCNC 的标准。但在这一点上，Grbl 现在在很多方面都比 NIST 更符合 LinuxCNC。

对于 G92.2 和 G92.3，LinuxCNC 将偏移量存储到内存中。它与运行偏移量分开。您可以显式清除存储的偏移量或获取它们。Grbl 不支持这一点，除非有充分的理由，否则我预计不会很快支持。

长话短说，目前的提议保持不变。我需要检查是否在 M2/30 上处理主轴速度 S、进给率 F、刀具编号 T 和 G43.1 刀具长度偏移。当我有时间时，我可能会尝试让 LinuxCNC 虚拟机稍后运行，就像你所做的那样。

我可以稍后为您检查并报告。我现在有一些事情要做，但可以在下午晚些时候检查。

这是它的样子。我只是使用 LinuxCNC 模态列表来检查。显然有些不适用于GRBL，但我都做了。

运动（第 1 组） G0、G1、G2、G3、G33、G38.x、G73、G76、G80、G81
G82、G83、G84、G85、G86、G87、G88、G89重置为
G1

平面选择（第 2 组） G17、G18、G19、G17.1、G18.1、G19.1
复位到 G17

距离模式（第 3 组） G90、G91重置为
G90

圆弧 IJK 距离模式（第 4 组）G90.1、G91.1
不复位

进给速度模式（第 5 组） G93、G94、G95
复位为 G94

单元（第 6 组）G20、G21
不复位

刀具直径补偿（第 7 组） G40、G41、G42、G41.1、G42.1
重置为 G40

刀具长度偏移（第 8 组） G43、G43.1、G49
不复位

固定循环返回模式（第 10 组）G98、G99
不复位

坐标系（第 12 组） G54、G55、G56、G57、G58、G59、G59.1、G59.2、G59.3
复位到 G54

控制模式（第 13 组） G61、G61.1、G64
不复位

主轴速度模式（第 14 组） G96、G97
不复位

车床直径模式（第 15 组）G7、G8
不复位

停止（第 4 组）M0、M1、M2、M30、M60
本次检查的主题

I/O 开/关（第 5 组） M6 Tn

换刀（第 6 组） M6 Tn

主轴（第 7 组）M3、M4、M5重置为
M5

冷却液（第 8 组）（M7 M8 都可以打开），M9重置为
M9

超控开关（第 9 组） M48、M49重置为
M48

S 主轴转速
不复位

T 工具编号
不重置

刀具长度偏移
不重置

F 进给速度
不复位

希望这可以帮助

约翰·B。

@109JB： 哇！这是非常彻底的！谢谢你这样做。有趣的是看看什么被默认，什么没有。它与软重置绝对不同。

@109JB：我一直在努力更新程序停止控件并实施您发现的内容。一件不清楚的事情是“刀具长度偏移不会重置”。这应该包含在模态 g 代码组 8 中。当通过 G43 应用偏移时，您是指刀具长度编号的“H”字吗？

正确的。我真的没有办法直接查看 H 参数以了解它的实际作用，所以我做了以下操作：
G90
G49
G0X0Y0Z0 (DRO 读取 Z=0.0000)
G43.1Z0.500 (DRO 读取 Z=-0.5000)
M2 (DRO 不变)
M30 (DRO 不变)
G49 (DRO 变回 Z=0.0000)

我还通过在刀具表中输入长度 = 1 并使用 G43 的刀具来检查它

基于此，我推断 LinuxCNC 即使在 M2 或 M30 命令之后仍保留当前的刀具长度偏移值。我不能说它是否保留了 H 值，或者它是否只记住了长度偏移量。至少后者是这样，因为 DRO 没有变化。

全部：我刚刚将 M0/2/30 的修复推送到边缘分支。在将更改拉入主分支之前，我需要一些志愿者来测试更改。

我还更改了归位的工作方式，以帮助用户诊断限位开关接线问题，方法是让归位周期的定位部分不移动太多。它现在向极限方向移动，将限位开关拉出拉出设置距离，然后缓慢移入限位开关以确定轴原点位置。它的行为要干净得多。

如果有人对 M0/2/30 或新的归位程序有任何问题或问题，请告诉我！我想现在解决任何问题，而不是以后！谢谢！

如果我正确阅读了新的归位代码，它看起来会将归位位置从机器中心移开传感器滞后量。这不是一件坏事——对于某些传感器类型，“开启”触发点可能比“关闭”点更可重复。但是您可能应该警告用户先前校准的位置可能会发生变化。

@ashelly：感谢您的评论（以及极限状态检查建议）。两个有效点。不过你是对的。归位周期现在基于触发位置而不是释放来定位归位。通过这样做，我能够摆脱拉断动作代码并节省几百字节的闪存。它还使归巢行为更清晰，并在视觉上更好地理解 Grbl 正在做什么。

我希望对于大多数用户来说，这种变化不会成为问题。对于 OEM，它可能会破坏他们存储的偏移量。在合并这个问题之前，我将等待听取人们的意见。

根据开关关闭而不是打开来设置归位位置可能更准确和可重复，所以这是一个好主意。许多开关具有迟滞，因此起始点和偏移量不同。根据我们的一些用户所做的测试，发作似乎更具可重复性。

一切都好。实施了极限状态检查，以确保开关在拉出时被清除。如果没有，归位将报告失败。我已经尽可能多地对其进行了测试，并且一切似乎都运行正常。有人愿意对边缘分支进行一些测试吗？我想让这个尽快掌握。谢谢！

此修复程序已被推送到 master。请立即报告任何问题。谢谢！