我能够重现 SF 问题 431 中的问题。SF 问题 432 中的问题用以下顺序演示：

• Ran linuxcnc ../configs/sim/axis/axis.ini &，切换 estop 和机器功率，归位轴
• 通过发出 MDIG10 L2 P2 Y-1和G10 L2 P3 Y-2
• 已加载nc_files/systems.ngc
• 测试 1：
  • 观察预览显示中的标签看起来正常，X 宽度在 0.01 和 2.67 之间
  • 运行程序和观察到的运动正确匹配预览显示
• 测试 2：
  • 发布MDI G21；观察到的模式行包含G21但预览仍以英寸为单位
  • 运行程序并观察到模式行重置为G20和运动跟随预览，均以英寸为单位
• 测试 3：
  • 发布MDI G21；观察到的模式行包含G21但预览仍以英寸为单位
  • 发行的MDIG0 X0 Y0 Z0
  • 运行程序和观察到的模式行保持在G21，预览保持以英寸为单位，但运动以毫米为单位运行

@robEllenberg，我在state-tags-master分支机构中找到许可为 GPLv2（仅）的文件。我可以将许可证更改为 GPLv2 或更高版本吗？

请注意，根据项目政策，新提交给 linuxcnc 的内容需要包含在 GPLv2+ 中。GPLv2(only) 不行。

当然，我认为他们没有理由不成为 GPL 2+。出于法律目的，
我应该提交更新它们吗？

在 2016 年 8 月 10 日，星期三，下午 3:26 John Morris notifications@github.com写道：

@robEllenberg https://github.com/robEllenberg，我在
state-tags-master 分支中找到了许可为 GPLv2（仅）的文件。我可以将
许可证更改为 GPLv2 或更高版本吗？

—
你收到这个是因为你被提到了。

直接回复此电子邮件，在 GitHub
#134（评论）上查看，
或将线程静音
https://github.com/notifications/unsubscribe-auth/ABJ6PHR7hrRvHOyUnckmlUlIDWdyfeQFks5qeiXSgaJpZM4Jfg-S
。

@robEllenberg，我认为您的许可就足够了。感谢您的回复，并感谢状态标签的工作！

我已经准备了一个基于最新 2.7的分支，其中包含最新的一组更新。它解决了问题@cradek在上述两个 SF 问题中报告，并修复了#138，其中 interp 和 canon 状态在中止后可能不同步，这与@cradek对中止恢复的额外关注。

我真的很感激评论@robEllenberg,@cradek和@SebKuzminsky，如果可能的话，我会尽快提交 PR。谢谢！

对我来说看上去很好。我在模拟中快速验证了 SF 问题 431 和 432 已修复，并且中止恢复似乎在坐标系中按预期工作（活动 G 代码匹配佳能/运动坐标）。此外，我在这里添加了一些代码清理，但没有功能更改。

[zultron 和我亲自讨论] 在激活 G92 期间中止程序后，DRO 仍然显示 G92 偏移量，但如果你 MDI g0x0y0 它会回到原点，就好像没有应用 G92 一样。我认为解决方法是添加 G92.2/G92.3（也称为“应用 G92 偏移量”）作为新模式组，将其添加到活动 GCodes 读数中，并将其添加为新状态标志，也许像

state.flags[GM_FLAG_G92_APPLIED] = settings->parameters[5210] != 0.0;

@zultron @SebKuzminsky请查看 glo/statetags

我认为它已准备好合并。（我添加了上面抱怨的 G92.x 处理）

@zultron @robEllenberg再测试 glo/statetags，我发现一个新问题。当我在子例程的深处中止时，我收到解释器错误：Unknown oword number

要重现，构建 glo/statetags，运行 sim/axis/axis，F1 F2 home all，打开 flowsnake.ngc，必要时触发 Z 让它运行，运行，等到它到达 XY 运动，按 ESC。预期行为是没有错误消息，实际行为是上面的错误消息。

平分显示第一个错误提交为：
2a39e3a statetag：添加了额外的标志以防止在重新映射中途中止时恢复 interp 状态

谢谢@cradek， 我会看一看。

我对 G64 很担心——看起来单独对 G64 进行编程会重置 P 值和 Q 值，而状态标签正是这样做的。考虑到#177也会影响是否保留 P- 和 Q-，我不确定如何对此进行测试。查看 IRC 对话：http ://tom-itx.no-ip.biz:81/~tom-itx/irc/logs/%23linuxcnc-devel/2016-11-15.html

对于最终用户来说，这听起来也是一个潜在的问题。使用 g 代码命令来更改混合模式而不更改公差值会很有用。如果我们有它，那么状态恢复就可以使用它。另一种可能性是将公差存储为标签的一部分（然后恢复它）。这样，即使用户在程序中更改了公差，它也能正常工作。

我正在考虑使用 Rob 的状态标签工作来解决 G64 问题。正如我在#177中所说，我有一个单元测试可以证明这个问题。它比必要的更长，因为我在开发修复程序时也在使用它。

我正在处理的修复程序遵循 Rob 的建议以保存/恢复标签中的公差。

回顾这个问题，它看起来像 G64 和@cradek这里是Unknown oword number最后两个悬而未决的问题。我将尝试在下周左右解决这些问题。

PR #283解决了 G64 问题。 Unknown oword number问题仍然悬而未决….

至于@cradek的问题，由 bisect 发现的提交2a39e3aUnknown oword number是问题的核心（这是一个转移注意力的问题；这可以稍后解决）。

提交之后，如果状态标记来自子或重新映射，则它被标记为不可恢复。至少在我的回归测试中，错误源于：

• emc/task/emctaskmain.cc, emcTaskIssueCommand(), 案例EMC_TASK_ABORT_TYPE, 致电：
• emc/task/emctask.cc, emcTaskStateRestore(),pinterp->restore_from_tag()线

尽管打印了错误消息（启用状态标记和 interp 调试标志时会出现更合理的错误），但这不是致命错误。

我理解为什么标签至少在重映射中应该是不可恢复的。它似乎@robEllenberg认为在重新映射或子中中止是可以跳过恢复状态标记的极端情况。我还不知道后果，但会在考虑一下后报告。与此同时，我很想听听其他人的想法。

对这项工作还有兴趣吗？我有一段时间没有更新这个问题，因为我在非运动佳能命令中添加了对状态标签的支持，这解决了 M0/M1 程序暂停时状态缓冲区不正确等问题，并且仅在几个月内才合并到 Tormach 的生产分支中前摇出各种问题后。在这一点上，更新看起来非常可靠，所以可能是时候重新考虑将状态标签合并到 LCNC 中的可能性了。

任何更新？还是有兴趣的。

我们合并了吗？

我似乎找不到相关的 PR，但也许开发人员正在直接推送到主线分支。此相关文件在master分支中：

https://github.com/LinuxCNC/linuxcnc/blob/master/src/emc/motion/state_tag.h

我要关闭这个。