引用56楼详细内容：

别去扯Modbus TCP，在通讯上完全两码事儿。

在全部西门子产品搭建的系统上，我不喜欢用Modbus RTU，它完全是为连接第三方设备开发的。

比如使用西门子控制器和西家变频器，虽然都有Modbus RTU，但那是分别为第三方提供的。在这个系统中，完全没有必要使用这个协议。

至于西门子设备之间 Modbus TCP，一直是可靠运行。网络断开-重连；根本不需要人工干预。

引用53楼详细内容：

真是精彩啊，粗略看了看，不否认Zane版的Modbus轮询的优秀，但是也更应该吐槽西门子的问题。。。

通讯故障出现偶尔卡死并不是一个两个人遇到了，我相信Zane版最开始也遇到过此类问题。

我们轮询写一些各类的“补丁”程序很大一部分就是希望如何去修补通讯卡死的问题，避免通讯卡死的产生。

但反过来是否能够想过为何西门子不去解决卡死的根本原因？就算出现了卡死，为何就没有什么办法让通讯重置，让通讯重新恢复正常？

其实基础的库或者基础的程序就应该必须考虑各种使用情况的稳定性，尽量避免错误的产生。如果基础的程序都有各种坑必须要编程人员想方设法去避免落坑那么此基础程序是否该去反思修正？

从Modbus轮询到ModbusTCP的轮询应用其实都存在着一定应用隐患问题，当然西门子可以说Modbus轮询卡死是你程序不好，你EMC没做好，你的现场设备的问题。。西门子也可以说ModbusTCP本来就不是给你轮询使用的等等冠冕堂皇的结论，但西门子是否有没有反思去修正相关的程序块从而保证程序的稳定性，抗干扰性以及应用的普遍性呢？

最近在做1500冗余的项目，1500冗余互相间的通讯问题也一直让人困扰，有些问题的产生就不明白西门子的开发人员是怎么想的。。我会抽时间写一个简单的1500冗余通讯可能遇到的坑，好让大家去跳过这些坑。