您是要实施单一工作坐标系 (G54) 还是多个 (G55 – G59.3)？看起来单个 G54 是个好主意。我们可以简单地将 G92 映射为替代 G54 还是在行为上存在差异？

–（稍后编辑）我刚刚回顾了 NIST RS274/NGC v3，第 3.2.2、3.5.5、3.5.13 和 3.5.18 节。还有更多。
G54 用于选择活动坐标系，G10 用于将偏移量应用到活动坐标系以满足归零和其他需要，G92 和 G92.3 用于将（临时）偏移量应用到坐标系。可以使用 G92.1 或 G92.3 取消偏移

所以我的问题是（1）这是否是 Gcode 生成器世界实际期望的方式 – 根据 NIST 可能会或可能不会运行，以及（2）您认为其中有多少是有意义的？

当我刚才看这个时，我回避了坐标系，只是使用 G92 作为一种简单的方法来归零，而无需管理所有这些。至少那是 TinyG 所做的，我不能代表 grbl 中的实现。如果您想保留单独的机器和工作坐标系，这种简化似乎会失效。

我曾与迈克争论过让事情保持他们目前的样子，主要是为了保持简单。他对此毫不留情，我同意他的看法。实施 G54（以及可能更多的工作坐标系）是要走的路，以保持标准并能够让用户轻松理解其他 CNC 系统。

最近我添加了一种在重置时保持机器位置的方法。当我这样做时，我无意中添加了管理坐标系所需的所有功能。通常，您所要做的就是保留每个工作坐标系的坐标偏移量，并在发生变化时将它们应用于 g 代码解析器和规划器。事实上，我不需要做太多事情就可以让它工作。（我认为）。所需要的只是一些用于存储这些的内存分配：每个坐标系 3 个双精度数/int32。所以，很容易添加我们想要的数量。此时只添加 G54 或更多是否有意义？我认为添加一个很好，如果用户想要添加更多，则在代码中编写一个注释过程。

关于这一点的另一个注意事项。G10 是一种在程序内存中设置 G54+ 工件偏移量的 g 代码方式，但这并不是在传统 CNC 机器上执行此操作的唯一方式。他们中的大多数都有特定的物理按钮来在机器上执行此操作，因此如果我们提供另一种通过“$”界面设置它们的方法，grbl 就没有必要支持 G10。

至于 G92，我同意这可能是处理工作坐标系的最简单方法，如果我们没有其他方法的话。G92 确实增加了一些复杂性，因为它的功能有点奇怪。我认为我们决定保留 G92 并添加 G54+ 工作坐标系，还需要添加 G92.1+ 命令。我在想我们应该放弃 G92，但是有人想让 grbl 保留这个吗？

桑尼：听起来像是一个合理的分析。

我实现了一种类似的方法，其中值在进出 gcode 解释器的过程中通过翻译层传递。所有坐标运算均以内部规范形式执行，即以毫米为单位的机器坐标系。向该适配器层添加工作偏移量相对简单。（我已经看到一些 Gcode 实现不能以这种方式工作，如果您更改坐标系，它们会发疯）。

我只支持一个坐标系，即 G54，至少目前是这样。在添加更多之前，让我们看看是否需要更多。

对于 G10，无论您是否可以使用 $ 命令设置偏移量，我都希望能够使用 G10s 来执行此操作。NIST 在 5200 系列中指定了一堆参数，用于选择坐标系并指定偏移量（参考：3.2.1，表 2）。虽然我们不需要复制数字系统，但（实际上）这就是我们通过存储这些值所做的事情。

听起来如果你有 G54 和 G10 就没有必要有 G92，但我认为我对用例的了解还不足以提供明智的意见。这是人们希望如何执行归位/归零操作的一部分吗？听起来不像，但我可能是错的。G92 是否有用于手动编码子程序的用例，例如复制模式？我们关心手工编码的 Gcode 吗？我认为我们需要在这里进行更多探索。M. Mike 似乎表明它没有被使用，因为它不是标准的，这可能是最终的答案。

如果您有标准工作坐标，G92 似乎没有多大用处。您应该能够做完全相同的事情，但输入将是机器坐标，指示工作零与您想要的。有点不同，但相同，特别是因为 grbl 现在报告机器坐标。如果删除 G92，我认为最好安装 2 或 3 个工作坐标系来补偿它的损失。M. Mike 指出 6 个工作坐标系是所有机器的标准配置，更大的通常是附加包。

至于手工编码，我在实验室的机械车间实践中经常看到这种情况。正如您所说，主要用于复制模式。与在 CAM 程序中创建多个操作相比，直接在 g 代码中执行此操作要快得多。不过，由于 G54+ 可以做同样的事情，G92 的丧钟已经敲响。

翻译层的好主意。我会尝试整合类似的东西。它可能必须驻留在 g-code.c 源中，以便它可以轻松转换 G53 非模态绝对调用。

我不认为对 G92 有感情依恋，但我认为很多人已经在他们的控制台程序中使用它来将机器归零。所以这些游戏机会随着新版本的出现而崩溃。我并不是说事情应该或不应该向后兼容，这只是一个观察。我认为应该提出向后兼容的问题。

6个工作坐标系。嗯。这是很大的灵活性。我们知道 grbl 用户使用的常见 Gcode 生成器是否支持此功能 – Pycam、CamBam、ReplicatorG 等，以及手工编码的 Gcode？我很想在 6 中粗略，但从 1 开始。

Simen 早期“使命宣言”的一部分是支持普通机器生成的输出——这就是为什么像刀具长度偏移和刀具半径补偿之类的东西不在那里的原因——因为它们通常在 Gcode 生成器中处理，而不是 Gcode 本身。最好讨论一下手工编码的 Gcode 的方向。增加对手动生成的 Gcode 的支持最终会让您沿着上述路径走下去，可能还有子例程（O 代码）、表达式求值和一堆其他东西。

关于向后兼容 G92，你是对的。我主要试图避免支持 G92 的其余部分，即 .1、.2 和 .3 命令。没有它们，G92 可能无法使用标准工作坐标系进行管理。

同意六个工作坐标系很多，但这是生产机器上的标准。Grbl 不一定要遵循这个框架，但它肯定需要至少有一个工作坐标。

至于手工编码，我认为 grbl 永远不会支持宏或函数，但您仍然可以使用它已有的标准 gcode 做很多事情。我认为唯一缺少的是所有 CAM 系统都支持的工作坐标，因为 G54 始终是默认设置。

无论哪种方式，我都会不情愿地尝试看看安装其余 G92.X 命令以及两个工作坐标系需要什么。我可能只启用一个并注释掉另一个以供用户参考。

这一切都是有道理的。让我知道探索的进展情况。我会做类似的工作。我确实认为 G10 很重要，并且正在努力通过一种方式来支持 G10 和 $ 操作来设置偏移量。

听起来不错。我也会安装G10。

同样在查看 G92.x 命令之后，我认为我不会包括 G92.2 和 G92.3。这些需要将偏移量保存在内存中，并且在程序之间重新启用时，这些偏移量可能会导致一些问题。（史密斯）我认为最好在重置和禁用时始终将这些偏移量归零。

好消息！今晚一切正常，它实际上简化了坐标管理，只允许规划人员查看机器坐标系并让 g 代码解析器处理所有翻译。我写它是为了让 grbl 可以通过编译时配置选项支持多达 6 个工作坐标系。它将默认为一个。工作坐标系将在软重置时保留，但不会在电源循环时保留。（如果需要，可以是 eeprom 可以做的事情。）

此外，我重写了部分解析器以进行错误检查，例如模态组和缺失参数。它并没有把事情搞砸。仅大 1.5kbyte 的闪存。

我必须彻底测试所有内容，以确保没有其他地方无意中破坏并稍微清理和优化代码。应该在本周晚些时候发布。