我对使用 G92 的“归零”不太在意。但我确实觉得奇怪，“归零”使用机器坐标，而不是刚刚设置的工作零，并且不一定归零（即 0,0,0），而是移动到预设的机器参考点（即按钮标签的错误选择就是我所说的）。然而，我确实支持能够禁用/隐藏/自定义按钮的概念（正如许多人已经建议的那样）。

然而，我对工作位置的真正抱怨，我不完全确定这是一个 GCode 发送器还是 GRBL“功能”设置了一个工作偏移量（“重置零”，G92）然后“发送”一个 GCode 文件。工作完成后，工作偏移量被神奇地清除（工作坐标 = 机器坐标），这意味着您必须再次重新找到零件零。我不确定为什么在成功完成发送文件后必须做任何事情？除了坐下来等待更多命令或另一个文件甚至再次相同的文件？几乎就像发生了隐藏的软件重置，但我不确定是哪一端发起的。据我所知，M30“程序结束和倒带”命令的重点是能够再次重新运行文件（无需重新调整任何东西）

我注意到 M30 的行为很奇怪，我不再把它放在我的程序中了。问题解决了。

至于工作坐标系是如何工作的，它们工作得很好，我一直在使用它们，但我从不使用 G92。

您可以在此处了解我如何使用它们：http: //www.shapeoko.com/wiki/index.php/G-Code#Using_the_Work_Coordinate_Systems

@steam21：根据定义，M2 和 M30 重置系统默认值，这包括 G92 偏移量。作为@twforeman指出，将 G92 用于您想要保留的工作坐标偏移不是一个好主意。机械师会告诉您，由于这个原因，他们不经常使用 G92（如果使用的话）。Grbl 将其作为一项遗留功能保留下来，并作为用户/GUI 设置工具偏移量而无需更改工作坐标位置的变通方法，因为 Grbl 不正式支持工具偏移量。

好的，所以 G92 应谨慎使用，G10 是设置工作偏移的首选/正确方法。至于作业完成时的“系统重置”，这是 GRBL 的理想设计功能（与 GCode Sender 无关），实际上是响应 M2 / M30“End Prog”功能，而不仅仅是发送文件结束。

感谢您的澄清。

@steam21：在 Grbl 的最后，确实没有办法区分程序何时完成或流发生了什么事情，也就是饥饿。Grbl 不控制流或程序的来源，所以它所能做的就是重置系统，就像它已经做的那样。如果你想要它真正符合 g 代码标准的技术，我们可以让 M2/30 在完成排队中的内容后停止所有进程，并在完成重置之前等待循环启动命令。我们选择反对这样做，因为对于菜鸟通过串行终端直接与 Grbl 交互来说，这只会让事情变得更加混乱。

但是，我不同意 M2/M30 的其余部分应由 Grbl 处理。程序控制部分可以而且应该由 GUI 或 G 代码发送器处理。当它检测到 M2/30 时，界面应该简单地通过一些确认按钮通知用户流式传输已完成，阻止发送任何剩余的 g 代码，并重置程序流式传输界面以再次开始流式传输。与此同时，Grbl 将完成流式 g 代码并重置自身，为下一个程序做好准备。

@winder我认为我们可以关闭它？

自 GRBL 0.9 以来，我们使用 G10 来设置工作偏移，我认为这已经足够好了。