注释
.jpg "使用多个用户界面进行错误处理 #2013"){kind=avatar}
合作者
|
[c-莫利]
多年来一直在努力解决这个问题，我一直在思考解决方案。对我来说似乎有意义的那个并不是什么新鲜事 – ZMQ 或等效广播错误，可能带有序列号。
考虑到零消息队列基本上是一个网络化的 Publis-Subscribe patter，<URL: https://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern >，而且 LinuxCNC 已经具备消息传递能力，难道它不会更简单地扩展 Linuxcnc 消息传递系统也可以进行发布-订阅。在我看来，这比引入 ZMQ 配置和维护的复杂性更简单。当然 ZMQ 会提供一些新功能，比如能够通过 Internet 传递消息。我只是不确定增加网络暴露是否值得，在安全性和复杂性方面，以改进 LinuxCNC 中的错误处理。
|
.jpg "使用多个用户界面进行错误处理 #2013"){kind=avatar}
合作者作者
|
扩展 NML 可能更容易，我不知道 – 希望有知情人士发表评论。 切换消息系统的一个原因（曾经有人谈论过要摆脱 NML）是因为有现成的库由该领域的其他专家维护、测试、改进和记录。 除了 HAL 之外，用户程序以某种方式相互交谈也很好，因此也许可以扩展/重新库化状态和错误处理。 无论如何，制造潜在的致命机器，正确中止并带有有用的消息肯定会很好。 |
这是读取 linuxcnc 错误通道的多个程序的一个长期已知的基本问题。
由于消息在读取时会被消耗，因此它会产生竞争条件，可能会干扰捕获和处理错误。
这与没有确定的方法来了解特定 MDI 命令是否正确无误地完成有关。
例如，在创建探测屏幕时，中止或其他运动错误将停止当前命令，但程序不知道停止发送更多命令。更深入地思考，使用 MDI 确实不是制作此类程序的最佳方法，但目前我们只有这些。
添加到此的是 python 程序，每个程序都在自己的上下文中运行，因此每个程序都读取错误通道。
多年来一直在努力解决这个问题，我一直在思考解决方案。
对我来说似乎有意义的那个并不是什么新鲜事 – ZMQ 或等效广播错误，可能带有序列号。
我实际上可以通过在 linuxcnc 和 python Gstat 库之间添加一个“shim”程序来对此进行试验。
不过最终，我认为如果 linuxcnc 自己使用这个广播程序与所有事物对话会更好。
还有其他相关的事情可以与这个讨论一起进行，例如无法轻易过滤 GUI 的错误消息，这真的很烦人。我认为 linuxcnc 向 GUI 发送某种代码，然后由集成商决定过滤掉什么以及实际向用户打印什么会好得多。
这个问题标志着我们知道这个问题，并希望就最佳解决方案展开一些讨论。