@SebKuzminsky我现在可以从此错误中删除影响 2.6/2.7 的标签，对吗？

我试图在 2.6 中解决这个问题（并合并到 2.7 和 master），但我的补丁引入了其他问题。我在 2.6 和 2.7 中恢复了有问题的修复，但将其保留在 master 中。我打算修复 master 中的剩余问题，然后我们可以考虑是否值得向后移植到稳定版本分支。

我现在认为我最初的错误报告有部分错误。

在 2.6 中，提交48daf71（在我损坏的任务更改之前），运行程序完成（即 M2）具有记录的行为，至少就坐标系而言：活动坐标系重置为 G54，独立于什么当遇到 M2 时，它在程序中处于活动状态。这反映在状态缓冲区中的活动 gcode 列表中，以及状态缓冲区中的坐标系和坐标系偏移中。

但是，在该提交中，中止更改坐标系的程序会导致最初报告的不一致状态@zultron：状态缓冲区的“活动 gcode”正确地包括 G54，但状态缓冲区错误地指示在中止时处于活动状态的坐标系和坐标系偏移。

@SebKuzminsky，我看到#138可能是这个问题的重复，我很抱歉。

我想指出的是，在 M2 之后对 G54 的更改是在中故意完成的convert_stop()，而中止后有效的坐标系（或系统！）取决于特定的程序；请参阅我在#138中的评论。此外，我在更新的状态标签分支statbuffer-g5x-abort中有一个修改后的测试，它演示了这种微妙之处。

是否有某处的文档或标准显示在 m2 或中止或任何 其他状态更改
时坐标更改应该预期的“正确”行为？
我坐在一个旧版本上，
很快就会升级 v，很高兴知道会发生什么。这里不清楚。

谢谢！

在 2016 年 8 月 19 日 00:16，“John Morris” notifications@github.com写道：

@SebKuzminsky https://github.com/SebKuzminsky，我看到#138
#138可能是
这个问题的重复，我很抱歉。

我想指出，在 M2 之后对 G54 的更改是在
convert_stop() 中故意完成的，而中止后有效的坐标系（或系统！）
取决于特定的程序；请参阅我在#138
#138中的评论。此外，我在更新的状态标签分支https://github.com/zultron/machinekit/tree/state-tags-master-lcnc-2.7
中 修改了 statbuffer-g5x-abort 测试， 它展示了这种微妙之处。

—
您收到此消息是因为您订阅了此线程。
直接回复此电子邮件，在 GitHub
#126（评论）上查看，
或将线程静音
https://github.com/notifications/unsubscribe-auth/ACafMl7ULwrl3GyGaH1KSTBPVlSpbsKKks5qhS36gaJpZM4JXlnM
。

@VladAlpha，程序结束时（M2 或 M30）的行为记录在此处：http ://www.linuxcnc.org/docs/html/gcode/m-code.html#mcode:m2-m30

Abort 的行为记录很少，这也是我之前搞砸它的部分原因。这是我能找到的微薄文档：

• http://linuxcnc.org/docs/2.7/html/code/code-notes.html#_abort
• http://linuxcnc.org/docs/2.7/html/code/nml-messages.html#_emc_task_abort_type
• http://linuxcnc.org/docs/2.7/html/gcode/coordinates.html#_setting_g92_values
• http://linuxcnc.org/docs/2.7/html/gcode/m-code.html#mcode:m73
• 和我最喜欢的http://linuxcnc.org/docs/2.7/html/user/user-intro.html#_modes_of_operation，它说 Abort 是“不言自明的”……

作为解决此问题的一部分，我想添加有关 Abort 究竟做了什么的文档。我将在这里总结我的目标：Abort 应该继续做它一直做的事情，但没有错误

这是 abort 一直在做的事情，或者至少从 2.6 开始就一直在做的事情（请检查我的陈述）：

• 预览：将设置最后执行块时有效的偏移量，如在 DRO 和原点中可见
• Interp：偏移量将在状态缓冲区中和通过 MDI 运动命令可见，如下所示：
  • 如果队列中断器跟随程序中当前正在执行的块，则将设置在队列中断器处有效的偏移量
  • 如果没有 queue buster，并且程序以M02或结束M30，偏移量将重置为 G54 坐标

肯定有一个错误，但中止后的预期状态是什么？我看到三个选项；

1. IMO，预览中可见的状态，即在最后执行块时有效的偏移量，是人们所期望的（此外，他们最有可能看到的），并且应该重置 interp 状态以匹配。

2. 另一种选择是将 interp 的状态称为预期状态，并更新预览以匹配 interp 的偏移量。但是，我无法想象有人会期望这一点，尤其是在 interp 停止并在队列破坏者之前有偏移量的情况下；这可能是非常随意的，让运营商摸不着头脑，想知道这些偏移量是从哪里来的。

3. 我看到的第三种选择是重置所有内容，就好像 MDIM02跟在中止之后一样。IMO，这是不可取的，因为重置如此多的状态会使程序难以恢复（例如使用“从行开始”）或调试，并且由于清除工作偏移但保留任何有效的 G52 临时偏移会使事情处于另一种令人头疼的状态.