d92f694是唯一看起来像的，但涉及大量代码移动，因此似乎不太可能通过检查来诊断。

我不太可能和硬件呆在同一个地方，有时间看它，持续几周。

好的，下一个测试：

重置主机很难成为6f0f2ca
（control.c：车轮慢跑的荣誉分数加速）
工作正常！

硬重置为d92f694
（智能串行：开始通过 HAL 启用参数设置）
坏了！

所以恕我直言，合并会导致问题。

安迪，如果你想让我做更多的检查，我会做的。
如果你需要一台 7i76e 来测试，我可以借给你一台。

诺伯特

注意：如果我停止脚本，显示会停止，我可以看到，所有字母都向正确的位置移动了 1，所以你读的不是 LinuxCNC，而是 LinuxCNCC，所以这可能只是在某些地方计数错误。

你能打开一个 halrun，并在工作和非工作配置中显示 7i73 的引脚和参数吗？
打开 halrun，然后键入 show param 和 show pin。
多次运行 show 命令，查看某些值是否发生变化。

形成 lcd 手册页：“输出字节流通过此 pin 发送。每个线程调用发送一个字符。没有提供握手。”
也许这是问题的一部分？

仅当端口从停止状态转换为运行状态时才写入 sserial 参数。
即使那样，只有在值发生变化时才应写入这些值（并且我已采取预防措施以防止不同长度浮点数中出现明显的不相同值）
我想知道 hm2_eth 是否有可能有时会跳过一个字节。

我在点击发送后想到了这一点。显示内容必须在过程数据中，因为它每个周期都会更新。我认为以太网不会跳过一个字节。这使得这个错误更加奇怪，因为流程数据不受提交的影响……

也许在此期间，可以使 sserial 参数访问以命令行标志为条件。
这可以帮助调试问题，如果您不需要参数访问，也可以节省一些时间，因为如果您有很多 sserial 卡，它可以为 LinuxCNC 启动增加几秒钟

潜在的问题是，自去年 12 月以来，我只在家度过了 10 个晚上，而且已经把所有的时间都花在了这个问题上。（即我们的时间，而不是导致延迟的技术困难）

论坛上的一篇帖子报告说，在修复了一些错误后，LCD 现在可以正常工作了。

应用的任何修复都与出现问题的提交直接相关。我只能假设存在二阶效应。