这是因为（除了 MPG 之外）linuxcnc 没有“当前点动速度”、“当前点动增量”或“选定轴”的内部概念 – 每个 ui 都会跟踪它自己的。
所以它并没有从 python 模块中丢失 – 它从 linuxcnc 中丢失。

我不是很清楚为什么会这样决定——可能是为了最好的灵活性或最不严重的问题。
很难让它适用于所有控制范例，即在一个用户界面上使用物理选择器开关会使其他用户界面变得不清楚。
在 qtvcp 和 gladevcp 中，我们扩展了 python 接口以包含“自愿”点动速率/增量。
不幸的是，由于 python 的限制，它只能由同一 python 上下文中的程序轻松访问。我已经使用 ZMQ 消息或使用 HAL 引脚解决了这个问题……

谢谢你。我不知道“后台”的东西，但根据你的解释，这是我脑子里嗡嗡作响的东西：

LCNC 保存进给/速度/快速覆盖的值，这些值可以通过 Python 由 GUI 检索。我相信这些是使用 python 接口通过 linuxcnc.stat(?) 可用的属性。

在这些情况下，连接到 halui 的外部控件会调整 LCNC 值，并且 GUI（滑块、状态显示）都可以通过 python 界面跟踪和调整 LCNC 值。双向沟通。

在jog-speed的情况下，LCNC没有持有内部值，所以没有相应的linuxcnc.stat属性。当点动命令从 GUI 发送到 LCNC 时，点动速度始终由 GUI 设置。单向沟通。

您在上面提到的 – HAL 引脚 – 是您在此提交中所做的：

https://github.com/LinuxCNC/linuxcnc/commit/da89022b89fe1d493f7a38fde4003786d6e475bd

看来您创建了一个 GUI HAL 引脚，它接受来自外部源的值——即 MPG 或其他。

所以，如果我理解以上内容（大如果）

如果 halui 可以调整 LCNC 点动速度值，即使 GUI 没有“看到”它，这是否意味着点动速度存储在 LCNC中的某个地方？我的 MPG/编码器 -> halui 肯定在调整点动速度值，即使 GUI 不知道。某些东西正在接收该值并将其存储以用于下一次慢跑。

如果不是……我要求的是更好地针对 GUI 开发人员而不是 LCNC 开发人员吗？也许他们可以在其他 GUI 框架之一中复制您的提交。

If halui can adjust the LCNC jog-speed value even though the GUI doesn't 'see' it, doesn't that imply jog-speed is stored somewhere in LCNC? My MPG/encoder -> halui is certainly adjusting the jog-speed value even if the GUI has no idea. Something is receiving that value and storing it for the next jog.
是的——在海陆。halui 只是另一个没有 G 的
GUI。halui 所做的任何事情都可以在 GUI 中完成。

通常是的，我们在每个 GUI 中都这样做，并处理由同时使用的任何其他 ui 产生的问题。
例如，我可以在 qtvcp 中复制所有 halui，然后“qtui”可以直接与 qtvcp 对话并可以访问当前的慢跑速度。然后我会要求人们不要使用 halui。

肯定不是最优的，但最简单，因为穿透 linuxcnc 的核心代码是痛苦的

您对提交的引用没有显示任何内容，因此我无法直接对其发表评论。

抱歉链接不好，我是 github 的新手。

由您提交，2021 年 8 月 20 日。编号da89022

我刚刚在 LCNC 存储库中搜索了“JOG_RATE”，并在提交的第一页上找到了它。

halui 作为一个“UI”现在更有意义，并解释了为什么/在哪里存储点动速度值。