更新：除了 TLO 和 WCS 之外，甚至还有人使用 G92 来处理工具更换……

工具表在这里看起来真的有点矫枉过正。但是将 TLO（可能还有 G92 偏移量）保存到 eeprom 中只需要几个字节。这在 grbl 级别应该非常简单和稳定，而在发件人级别有点脆弱。
当用户希望在每次控制器重新启动时重置 TLO 时，我可能会遗漏一些用例？因为在我的场景中，控制器重启几乎不会在工具更换时发生。

软复位通常用于停止运动，IMO 不应更改 TLO。

例如，在程序运行期间，当前唯一立即停止程序执行并取消 g 代码文件运行的方法是执行进给保持，等待机器停止，然后执行软复位以清除进给保持之后的所有命令的缓冲区。在这种情况下不应重置 TLO。除了完全关闭机器之外，据我所知，没有任何商业控制器会为任何事情重置 TLO。因此，硬重置可能可以让 TLO 重置，但对于软重置则不应该。这是我的意见

软复位通常用于停止运动，IMO 不应更改 TLO。

这就说得通了。

这在 grbl 级别应该非常简单和稳定，而在发件人级别有点脆弱。

是的。这正是我没有将补丁合并到 bCNC 的原因。
不过我想我们还是要等Sonny的意见……

工具表在这里看起来真的有点矫枉过正。

是的。我认为 GRBL 不应该存储工具表。如果我们需要工具表，我们应该在 GUI 中处理它。

328 上的 Grbl 没有空间来处理 TLO（主要是接口）。动态 TLO 被引入 Grbl 以允许 GUI 模拟真正的 TLO 和工具库。这从来都不是一个想法的解决方案，但它是我用有限的资源所能做到的最好的解决方案。

如果他们想要支持多个工具及其偏移，最终取决于 GUI。重置或任何电源循环后，无论哪个工具编号处于活动状态，我都会让任何 TLO 处于活动状态。如果工具编号在电源循环时重置，那么用户有责任记住更改工具编号，但这通常在 gcode 中。

@chamnit我认为没有人在谈论 Grbl 支持多种工具，而只是在谈论 Grbl 保留一个工具长度偏移值。我自己只是在谈论只保留那个价值。在我看来，这很容易成为一个安全问题。例如，如果 TLO 为正且执行重置，则 TLO 将重置为 0。然后，如果用户开始运行 g 代码，工具现在会崩溃，因为 TLO 已重置。由于软重置是取消保留命令和刷新计划缓冲区的唯一方法，因此它也是停止正在运行的程序的唯一方法。商业机器不会仅仅为了程序停止而重置 TLO，LinuxCNC 也不会，但由于 Grbl 没有其他选项，我知道它确实会重置 TLO。

在我看来，这很容易成为一个安全问题。

确切地。当您无论如何都松开 TLO 时，存储 WCS 有什么意义？

商用机器不会仅仅为了程序停止而重置 TLO

我想这是 GRBL 协议极简主义的结果​​。尝试用最少的功能做很多事情。突然之间停止和重置之间没有区别。我认为这通常是一件好事，但我们需要找出所有用例并制定一些实施指南。

根据定义，动态 TLO 在复位时归零。是的，它可能有问题，但定义明确。同样，考虑到约束和其他更高优先级（例如真正的实时覆盖），这是我能做的最好的事情。

老实说，我认为 328 上的 Grbl 是完整的。在不对其他事情产生负面影响的情况下，我没有什么可以塞进去的。在 ARM 上，这是一个完全不同的故事。我没有看到支持工具和适当的 TLO 有任何问题。

顺便说一句，有没有简单的方法可以找到哪些参数在 GRBL 重启/重置过程中持久存在，哪些仅在 RAM 中？

还有这些写的频率是多少？我注意到当我拔下 USB 供电的 GRBL 时，它有时会松动。这是为什么？WCO 是否在延迟后存储以防止通过过多覆盖闪存来磨损 arduino？

 [G54:0.000,0.000,0.000]
 [G55:0.000,0.000,0.000]
 [G56:0.000,0.000,0.000]
 [G57:0.000,0.000,0.000]
 [G58:0.000,0.000,0.000]
 [G59:0.000,0.000,0.000]
 [G28:0.000,0.000,0.000]
 [G30:0.000,0.000,0.000]
 [G92:0.000,0.000,0.000]
 [TLO:0.000]
 [PRB:0.000,0.000,0.000:0]

根据定义，动态 TLO 在复位时归零。

我不得不强烈反对上述说法。虽然在 Grbl 中重置为零 TLO，但我认为由于软重置必须用于 Grbl GUI 中的正常操作，因此您不能将它与任何其他控制器的重置进行比较。

例如，为了使用 grbl 停止正在运行的 g 代码程序，您必须使用软重置命令来清除缓冲区并取消暂停的运动命令。在其他商业和非商业控制器中，停止正在运行的程序不需要重置整个控制系统。因此，将另一个控制器的重置与 Grbl 中的软重置进行比较并不是同类比较。

我可以向您保证，如果您只是调用程序停止，我使用的商业控制器以及 linuxCNC 不会重置 TLO。Grbl 必须重置以清除缓冲区这一事实是不同之处。

如果有一个命令可以取消当前运动并清除所有缓冲区而不做任何其他事情，那么这将是最理想的事情。然后 GUI 开发人员可以决定是否需要重置任何内容。这是一项长期以来被要求的功能，我认为这是必要的。我知道在 328p 中它可能不可行，但在 ARM 版本中这绝对是我认为需要的功能。

您无法将其与任何其他控制器的重置进行比较。

其实在#592 @chamnit甚至建议如果你想实现“进给保持期间的慢跑”功能，你需要进行软复位……

@chamnit，你能看看我的拉取请求吗？它在这里添加了我们想要的内容并减少了闪存消耗。代价是额外的 8 字节 RAM 和一些 EEPROM。
我还没有在硬件上测试过它。可能有一些错误。但这足以证明我们想要到达这里。

如果增加的 RAM 使用量是不可接受的，或者如果您认为在断电期间不应该保留这些偏移量，那么这里是另一种选择。只是不要在软复位时清除这些变量。它应该有助于 99% 的用例。
实际上，即使在硬重置期间（在 noinit 部分），我更愿意保留这些偏移量，但 arduino 引导加载程序使得很难区分加电、掉电和外部重置源。

我认为对于 328，最好在 GUI 中处理这个问题
只需跟踪最后的 TLO 并将其留给最终用户。
如果用户在软重置后重新启动程序，则由他决定是否应用 TLO。
GUI 可以做的是提示/警告用户，如果 TLO 应用于上一个作业并且未被清除。

与在 grbl 代码中更改一个常量相比，这只是向每个现有 grbl 前端添加几十行代码行的问题。使用这个单行补丁保留一个 grbl 的分支并告诉人们如果他们想要足够的 TLO 或 G92 就使用它要容易得多。

@109JB: 终于抽出时间来研究这个了。看起来我在 G92 和 G43.1 的两方面都不正确。

LinuxCNC 不会在程序停止或软重置时重置 G43.1，但它会在重新启动应用程序时清除（至少就我的 live CD 构建而言）。奇怪的是这种行为在 LinuxCNC 文档中是如何未定义的。它只是说 G43.1 没有记录在刀具表中。它也没有说明 M2/30 程序结束时的行为。

另外看看 G92，NIST 和 LinuxCNC 文档都指出它记录在参数中，但随着时间的推移定义发生了变化。NIST 和更早的 LinuxCNC 版本在 M2/M30 程序结束时应用 G92.2。当前的 LinuxCNC 没有。G92 保持激活状态。

不知道我从哪里得到的印象是 G92 和 G43.1 在软复位和 M2/30 程序停止后总是清除，但这可能来自我经常咨询的机械师。他非常强烈地认为 G92 和 G43.1 都是事故发生的磁铁，因为他亲眼看到 G92 多次毁坏 CNC 机器，即使是经验丰富的机械师也是如此。您很容易误用它们而忘记它们是否处于活动状态。他总是告诉我不要使用临时偏移量，甚至从 Grbl 中删除 G92。

因此，我倾向于保持不变，只是在 wiki 上注意到这种差异。还有一个额外的考虑，即改变 G92 和 G43.1 的行为可能会导致用户和供应商出现更多问题，而这些用户和供应商已经习惯了它现在的行为方式。

也就是说，我可以提供添加/合并一个编译时选项来修复 G92 和 G43.1 行为以与 LinuxCNC 兼容。为此，G43.1 将一直保持活动状态，直到电源循环（尽管出于上述原因我不同意这种行为）。G92 需要更新以包含 G92.2 和 G92.3 并保存在 EEPROM 中。这是一个合理的妥协吗？

自 4 月以来一直在使用带有补丁#634的 grbl 。它完成了工作 – 不再有破损的工具和意想不到的动作。硬重置或断电后工具长度松动是预料之中的，因为这些事件表明日常工作开始或某种硬故障。