运行时请dmesg -w在树莓上跑一下，看看出现这种情况时有没有提示信息？

我使用 dmesg 查看 usb 内核子系统是否有任何问题，但没有。然后重新启动后，此行为停止。我假设可能无人值守的升级完成了更多的 python 程序处理时间可用。我的猜测是，这与时间有关，与 USB 不稳定性无关。

还有一个超时设置影响了 i bCNC 的通信，这可能已经解决了慢速机器上的问题。如果问题持续存在或重新出现，我会测试扩展它。

观察仍然是，当状态从连接到未连接时，没有关于生成原因的错误消息。我也很明显 USB 连接并没有真正断开，但状态确实连接状态没有恢复。可能可以通过将超时设置得非常低来复制此行为，因为它当前无法在我使用标准设置的原始设置上复制。我想可能有更多的超时设置，但代码中不太明显。就像隐藏在 pyserial 或任何使用的默认设置中一样。

你自己从http://github.com/gnea/grbl安装了 GRBL吗？人们经常对来源不明的怪异 GRBL 分叉有疑问。（例如，由供应商预装在板上）。

我没有看到 bCNC 中缺少正确的错误消息和 bCNC 发生某些故障时错误处理不当以及 GRBL 运动控制器源代码来源之间的任何伤亡。

为什么这个问题是相关的？

因为我们只支持 GRBL 和 grblHAL。
我们不支持来自未知来源的随机内容，这些内容可能是也可能不是松散地基于 GRBL。

即使有这个意图，您也需要处理由 bCNC 执行的平台引起的故障模式。我没有声称延迟（假设延迟是根本原因）是由运动控制器引起的。尽管我也不能排除这种可能性。但考虑到 Raspbian 不是实时操作系统，延迟更有可能是在 bCNC 主机端造成的。您是否意识到您的程序在抢占式操作系统下运行时可能并不总是以相同的速率执行？

是否意识到您的程序在抢占式操作系统下运行时可能并不总是以相同的速率执行？

bCNC 不是运动控制器，所以它不在实时模式下运行并不重要。GRBL 处理所有实时的东西。