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

我一直在尝试想出一种方法，让 GUI 和用户更清楚地了解正在发生的事情，而无需为所有 GUI 引入必须支持的新内容。

• 对于 M0 程序暂停，我可以让 Grbl 进入“保持”状态。这很容易。它应该是兼容的 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 发送者所知，该程序永远不会完成。

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

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

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

你好，
模式“检查”那里发生了什么？

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

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

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

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

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

如果在读取任何这些停止命令时向 EEPROM 中写入一点，并在执行 -> 软复位后读取 EEPROM 值并发送“ok”，难道不可能吗？或者可能是一个完整的字节，代表换行符和回车符的数量，以使用正确数量的“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，对于 GrblPanel 是否正常都没有关系。一旦检测到 Hold，我就会进入 Hold 状态。Hold 的来源应该无关紧要？

@gerritv：这应该无关紧要，但这并不意味着其他 GUI 实现以与 GrblPanel 相同的方式处理它。

@chamnit @gerritv：如前所述，如果没有 ok 返回，Universal G-Code Sender 会一直等待到无穷大。所以反馈会很好。由于我目前正在使用 SD 卡开发 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 并且 GRBL 在遇到 M2/M30 时重置，则 GUI 将获得其 OK 响应并重新启动数据流。即使 GRBL 报告类似于 [pgm end] 的内容，这是一个好主意，也必须编写 GUI 以了解此响应的含义并采取相应的行动。一个全功能的 GUI 应该已经在程序中看到了这一点。

关于拦截 GRBL 状态响应消息中的保持响应以便 GUI 知道有一个保持似乎毫无意义，我的程序没有这样做，下面是原因。正如我所见，暂停只会来自几件事：
1. 首先是用户（或 GUI）向 GRBL 发送暂停命令。这可能是 MDI 输入，或按下 GUI 上的“保持”按钮 在任何一种情况下，用户或 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 之后，由 GUI 停止发送程序中任何剩余的 g 代码。在这种状态下，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 系统运行，你能帮我一个忙吗？你能检查 M2/30 在 LinuxCNC 上关于参数和解析器默认值的行为吗？我特别好奇 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 代码标准文档指出 G92 应该在 M2/30 上取消。Grbl 最初是为了遵循 NIST 而编写的，而不是 LinuxCNC 的标准。但在这一点上，Grbl 现在在很多方面比 NIST 更符合 LinuxCNC。

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

长话短说，当前提案保持不变。我需要检查主轴速度 S、进给率 F、刀具编号 T 和 G43.1 刀具长度偏移是否在 M2/30 上处理。当我有时间的时候，我可能会像你一样尝试让 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

Arc 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”字吗？

Correct. I didn’t really have a way to view the H parameter directly to see what it actually does, so I did the following:
G90
G49
G0X0Y0Z0 (DRO reads Z=0.0000)
G43.1Z0.500 (DRO reads Z=-0.5000)
M2 (No change to DRO)
M30 (No change to DRO)
G49 (DRO changed back to Z=0.0000)

I also checked it by entering a tool into the tool table with length = 1 and using G43

Based on this, I reasoned that LinuxCNC retains the current tool length offset value even after an M2 or M30 command. I can’t say whether it retains the H value, or if it just remembers the length offset. It at least does the latter since there is no change in the DRO.

All: I just pushed a fix for M0/2/30 into the edge branch. I need some volunteers to test the changes before I pull it into the master branch.

I’ve also changed how homing works to help users diagnose limit switch wiring problems by having the locate part of the homing cycle not move as much. It now seeks toward the limit, pulls off the limit switch by the pull-off setting distance, and then slowly moves into the limit switch to determine the axis home location. It’s a lot cleaner in its behavoir.