引用59楼详细内容：

这又涉及到另外一个话题

品牌间的技术整合，到底是谁的责任？

我的观点，谁用谁的责任。没有金刚钻不揽瓷器活儿！

引用57楼详细内容：

首先不是所有工程都是用西家的东西，其实绝大部分情况下会有各种各样的第三方设备与西门子进行通讯！一句话Modbus RTU是为第三方设备开发的，所以我就有不稳定的理由！

一句话Modbus TCP是我们西门子直接设备通讯的，西门子之间通讯的是没问题的，所以与第三方如果需要用到轮询，不好意思，我程序虽然写了，但不完善不稳定，你们是不可以用的，用了不稳定有问题也不关我的事！

现在其实西家很多时候给人的感觉就是我是最大的，我是最牛的，我是最没问题的，有问题都是你们使用者的问题，有问题你们必须要想方设法去避免此问题，如果没有办法避免了那还是你的问题不是我西门子的问题！

我觉得这并不是一个开发者或者一个合格工程师该有的态度，更不是一个大企业该有的态度！

引用56楼详细内容：

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

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

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

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

引用53楼详细内容：

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

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

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

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

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

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

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