实际上，行为比这稍微复杂一点。加载nc_files/systems.ngc，并启动它。在G55标签开始切割的那一刻，模式行将显示为G55，但会G56在片刻之后更新。如果此时程序停止，状态比我们想象的还要奇怪：

• G55 中的预览读取：DRO、起源
• G56 中的其他部分：运动（G0 X0Y0），模态线

似乎除了 interp 中的块级重置之外，实际上几乎没有中止清理。谜团是这些部分如何不同步。

你好@zultron，我在#67中的补丁被合并到 2.6（并从那里合并到 2.7 和 master），但是正如你所说的，它们还没有准备好——我们发现了一些相当严重的问题，我在 2.6 和 2.7 中恢复了它们（尽管它们是仍在掌握中）。

我刚度假回来，我也打算回头看看部分修复引起的问题。

我认为那个分支（由 fixup 提交修改）@jepler和我; 如 master 分支的当前状态所示）在正确的道路上：改进 Interp 对 Abort 的处理以进行更彻底的清理，并改进 Task 对 Abort 的处理以不丢弃 Interp 需要进行的 Canon 清理。

@SebKuzminsky， 欢迎回来！

我发现 state tags 分支解决了这个问题，因为问题源于 interp 在运动之前运行。

原作者打算在中止后对机器状态进行轻微的处理：在Interp::on_abort()和之间Interp::reset()，只有一些块级清理在 interp 中完成。相比之下，模拟M02中止是相当笨拙的。希望，如果它保留在 master 中，如果/当状态标签工作被合并时，不会有人反对M02从 .ini 文件设置中启用/禁用行为。

是的，“Abort implies M2”行为过于严厉，并且是由于这项工作而出现的一些错误的原因。

我的意图是让 Interp 在中止时清理 Canon 状态，因为那是我认为问题所在的地方（因为那是跟踪活动坐标系的地方）。我很高兴听到状态标签的工作解决了这个问题，但是当你说问题源于 Interp 在 Motion 之前运行时，你是什么意思？当然，Motion 不知道或不关心哪个坐标系处于活动状态，并且中止时要返回的坐标系是 Interp 在开始运行当前 gcode 程序（或 mdi）之前激活的坐标系。

如果我误解了问题的原因，我很乐意接受教育，以便我可以正确解决它！:-)

如果我仍然在正确的轨道上，我显然（回想起来）超出了我的标记，Interp 现在在 Abort 上清理了太多。我需要控制它——当前的主行为不会出现在 2.7+1 中（有或没有 ini 设置）。

@SebKuzminsky，你是对的，motion 不知道坐标系，但实时程序执行受限于 motion 播放轨迹的速度，而 interp 可以尽可能快地排队命令，直到遇到 EOF 或队列破坏者. 运行第一个评论中的示例nc_files/systems.ngc，您可以看到 interp 和 canon 不同步：模型行坐标系，遵循 interp 状态，比预览运行得更快，它遵循 canon 状态。

@robEllenberg的状态标签的工作假设与物理机器上的实时程序执行相匹配的佳能状态是正确的状态，并且在中止之后，它是 interp 的状态，可能停止在未来的任意点程序，需要重置回执行停止时的程序状态。

这个假设对我来说很有意义，因为如果保留中止时间机器状态，程序更有可能被调试甚至重新启动。其他人说他们希望从他们使用其他控制器的经验中得到这种行为，但我自己没有那种经验。

@zultron我同意，稍微更正正确的状态（即从用户的角度来看是活动的）是当前正在执行的状态。Canon 状态与解释器状态匹配，因为解释大多数程序行的最后一步是调用一个或多个 canon 命令。Canon 确实有一些内部状态，但从概念上讲，它只是解释器的翻译层。

将状态标签视为行号的概括。Motion 知道特定命令的行号。除了将它报告给 emcStatus（并在单步执行时检查它）之外，它对这些信息没有多大作用。因此，我们对状态标签所做的就是将更多信息填充到该字段中。现在，motion 不再只是报告当前行，而是将整个标记呈现给 emcStatus。它不需要知道里面有什么。它所说的只是“我当前的动作匹配这个标签”。当任务将状态解包为活动 G 代码时，任务有责任实际了解标签的内容。

请记住，到目前为止我所说的所有内容都与中止问题无关。当您真正中止时，motion 不再有活动段，因此 Task 必须从解释器获取其状态。如果程序运行完成，则不会出现中断（因为运动已经赶上了解释器）。然而，如果我们提前中止，那么报告的活动状态会突然从中止行跳到预读行。不了解前瞻的用户充其量只会感到惊讶，最坏的情况是会造成损害。

这是状态标记恢复想法的用武之地。我们想让活动的 G 代码状态与程序中止的运动线相匹配。直接进入解释器/佳能是在自找麻烦。相反，restore_from_tag 函数模仿 restore_settings() 已经做的事情。也就是说，构造一个 G 代码序列，执行时会将解释器置于我们想要的状态。解释器实际上在这里解释 G 代码命令，因此 interp 和 canon 之间状态不一致的危险较小。