我的直觉告诉我，当您添加第 4 轴时发生了其他事情。
添加一个轴突然停止显示之前工作正常似乎不合理。
我想更多地了解“添加轴”的含义 – 您是否修改了 Gmoccapy 来执行此操作？
AXIS 不使用 GLIB，因此也需要解释一下。

话虽如此，可配置更新的想法并没有错。它可以帮助低功率机器。
gremlin 绘图更新实际上有一个 50 毫秒的内部更新以及一个在后台运行的 100 毫秒线程。
使用 Gladevcp 的 GPin 更新程序的 HAL 引脚有一个单独的 100 毫秒更新

如果屏幕变得饱和，它不太可能使正在运行的 linuxcnc 机器崩溃。实时任务是分开的。
我认为不需要添加监控——如果有问题，这是不言自明的——如果可配置，则很容易修复。

我也有点怀疑。我做了一些非常仔细的调试以得出我上面讨论的结论。我什至使用完全相同的部件构建了第二台计算机。我从头开始安装，我使用 3 轴版本中包含的 Gmoccapy 模拟器文件对其进行了测试，工作正常，但在 4 轴界面上失败。我将回调超时更改为 200，如上所列，并且有效。如果我将它设置为 110，它实际上工作正常，它在 105 时命中和未命中，在 100 时完全失败。当我使用 5 轴示例时，它必须在 120 左右才能可靠地工作。
我不同意监视 GUI 线程的一个关键原因是……点动按钮在 GUI 中。如果 GUI 落后，按钮的响应就会变得非常迟钝。这意味着当您将手指从按钮上移开时，可能需要几秒钟才能停止点动。到那时，如果幸运的话，您的工具可能会坏掉，这就是您造成的所有损坏……在许多情况下，只是没有时间去按下急停按钮。
如果有人想通过 SSH/VNC 玩我的测试设置，我可以在线使用它。
只是澄清一下，我没有测试我在 Axis 上所做的“调整”，到目前为止我只在 Gmoccapy 上测试过。
100 毫秒的屏幕截图：https
: //photos.app.goo.gl/HsVMJRriNtD3hDYH9 120 毫秒的屏幕截图： https ://photos.app.goo.gl/RJyYq5BjdgUZvh9J8

所以要明确一点，您是否也在未修改的模拟配置上看到了这一点？有趣的。

关于监控，我的意思是它不是来来去去的东西——如果这是一个问题，你就解决它，然后就结束了。
修好后监控就没有意义了。我想通过测试来确认问题可能会很方便。

您的更改对 AXIS 没有帮助 – hal_glib 用于 gladevcp、gscreen。gmoccapy 和 qtvcp。
AXIS 已经支持 INI CYCLE 时间设置。

我在上面编辑了我的帖子，我添加了屏幕截图。上面的屏幕截图来自未修改的 sim 文件 gmoccapy_4_axis.ini，3 轴 sim 工作正常。我认为额外的开销轴足以将计时推到边界之外，正如通过添加 20 毫秒使其工作所证明的那样。（需要说明的是，所有涉及的文件都直接来自大约 5 小时前的 git pull，唯一修改的文件是 hal_glib.py，如上面的屏幕截图所示。）
我之所以建议制作某种自动计时功能，是因为考虑到它现在的工作方式，无法判断您有多少计时余量。如果它位于边缘，它可能会在很长一段时间内被忽视，直到有人在熬夜，crond 启动了凌晨 2 点的维护任务，导致界面在他们进行设置时立即锁定. 按照软件当前的工作方式，当构建新机器时，您知道有多少时间开销的唯一方法是将其退回至失败，然后再添加一些。没有这方面的文档，所以在现实，你认为有多少人正坐在这个边缘？另外，坦率地说，即使它被记录在案，当我为额外的轴将配置添加到我的机器时，我也可能肯定会错过它。鉴于没有错误消息或警告，我很难找到。因此，即使它在 ini 文件中，它仍然可能是一个问题，除非软件按照我上面的建议对此进行了一些检查。也许实现这一目标的更好方法是反过来。使用空闲时间代替循环时间。该数字指定在触发下一个周期之前系统空闲的时间（以毫秒为单位）。这可以通过从 idle_add() 到 timeout_add() 回调之间经过的时间的 2 到 5 个桶滑动窗口平均值来完成。这将使系统能够适应临时后台负载。也许实现这一目标的更好方法是反过来。使用空闲时间代替循环时间。该数字指定在触发下一个周期之前系统空闲的时间（以毫秒为单位）。这可以通过从 idle_add() 到 timeout_add() 回调之间经过的时间的 2 到 5 个桶滑动窗口平均值来完成。这将使系统能够适应临时后台负载。也许实现这一目标的更好方法是反过来。使用空闲时间代替循环时间。该数字指定在触发下一个周期之前系统空闲的时间（以毫秒为单位）。这可以通过从 idle_add() 到 timeout_add() 回调之间经过的时间的 2 到 5 个桶滑动窗口平均值来完成。这将使系统能够适应临时后台负载。

这是一个有趣的问题。我不怀疑你的观察和测试。
至少我们应该能够毫不费力地使其可配置。

好的，我只是将 master 中的代码添加到 hal_glib 中以兑现 CYCLE_TIME，它实际上可以以毫秒或秒为单位！
让我知道这是否是朝着正确方向迈出的一步。

我只是拉动、构建和测试。通过对 .ini 文件中的 CYCLE_TIME 进行细微调整，它可以正常工作。所以绝对是一个很好的步骤。
我认为另一个好的步骤是一些关于 CYCLE_TIME 的一般文档，它比我能够找到的“显示将在轮询之间休眠的周期时间（以秒为单位）”更具描述性。我不确定这是否足以向机器制造商传达这到底在做什么。此外，它具有误导性，因为它特别暗示这是“睡眠时间”。如果是的话，我们就不会讨论这个了。它实际上是更新间隔，实际休眠时间取决于 update() 中所有代码的运行速度。

在这一点上，将它转换为睡眠时间将是微不足道的，只需让 update() 返回 False，并在返回之前重新调用 timeout_add()。在上层也可以做同样的事情。无论系统速度和用户空间负载如何，这种方法都不会受到饱和/抖动的影响。

我将了解如何将更多信息添加到文档中。
至于文档是错误的——它可能对某些屏幕是正确的。
没有什么审计 linuxcnc 看它是否真的遵循约定（也没有任何官方约定 – 至少在屏幕上）
我对编码更改睡眠 vrs 更新不感兴趣，但如果提交了补丁，我没有立即理由不这样做考虑一下。

我会考虑制作一个补丁，但这需要一些时间，因为我必须（更加）熟悉所有相关的部分。这就是为什么我没有立即提交补丁，我试图咨询比我更熟悉大局的人。从技术上讲，c-morley 的补丁是对所报告问题的确认修复，因此也许可以/应该关闭此票证。我会要求项目维护者做出决定。但是，如果弹出其他用户空间负载，它仍然会受到竞争条件的影响。我的观点是，任何 GUI 会根据系统负载进行竞争或抖动显然是一个错误，对于安全相关的 GUI，我认为这是不可接受的，所以我很乐意为它制定解决方案.

听起来不错。请记住 gscreen、gmoccapy、gladevcp 和 qtvcp 使用 hal_glib（虽然 qtvcp 使用它自己的 gobject 计时器），所以如果打补丁，请测试它们以确认它们仍然有效。

感谢您的报告和讨论。