恭喜,你发布的帖子
发布于 2020-06-07 12:21:04
58楼
真是精彩啊,粗略看了看,不否认Zane版的Modbus轮询的优秀,但是也更应该吐槽西门子的问题。。。
通讯故障出现偶尔卡死并不是一个两个人遇到了,我相信Zane版最开始也遇到过此类问题。
我们轮询写一些各类的“补丁”程序很大一部分就是希望如何去修补通讯卡死的问题,避免通讯卡死的产生。
但反过来是否能够想过为何西门子不去解决卡死的根本原因?就算出现了卡死,为何就没有什么办法让通讯重置,让通讯重新恢复正常?
其实基础的库或者基础的程序就应该必须考虑各种使用情况的稳定性,尽量避免错误的产生。如果基础的程序都有各种坑必须要编程人员想方设法去避免落坑那么此基础程序是否该去反思修正?
从Modbus轮询到ModbusTCP的轮询应用其实都存在着一定应用隐患问题,当然西门子可以说Modbus轮询卡死是你程序不好,你EMC没做好,你的现场设备的问题。。西门子也可以说ModbusTCP本来就不是给你轮询使用的等等冠冕堂皇的结论,但西门子是否有没有反思去修正相关的程序块从而保证程序的稳定性,抗干扰性以及应用的普遍性呢?
最近在做1500冗余的项目,1500冗余互相间的通讯问题也一直让人困扰,有些问题的产生就不明白西门子的开发人员是怎么想的。。我会抽时间写一个简单的1500冗余通讯可能遇到的坑,好让大家去跳过这些坑。
你说的有一定的道理,但是作为一款标准的产品,我们既然选用了,就应该是无条件相信,相信西门子的技术实力与产品质量,所谓疑者不用,用者不疑。
我们在使用中遇到的种种问题,主要应该是三个方面,对产品硬件的熟悉(电气安装规范,应用场合限制等其他各种限制)对产品软件的熟悉(指令系统,编程方法,包括各种限制),以及对系统的熟悉(产品的设计理念,选型依据,与系统的整合)。其实,这些问题大多数都是应该由用户自行解决的,西门子可以提供正确的技术信息及必要的技术支持。
作为一个25年一线支持的工程师,我的观点,你要抓住西门子的而小辫子真的还是不太容易的,关键是你是如何“信”的,为了这个“信”字,有多少用户自己是做了工作的?这是绝大部分,我不愿意多说,都是血泪史,但不值。
当然,会有意外发生,其实这是西门子与用户都不愿意的看到的,如何解决问题才是关键。
西门子是个庞大的体系,解决问题的流程冗长且漫长,这是就看问题是不是致命的,能不能绕过去。原则上是绕过去,因为大部分用户是等不起的。如果,证据确凿,或实在是绕不过去,那就请做好证据的搜集工作,能够复现故障现象,指出与技术资料矛盾之处,提交西门子的技术服务部门,一般至少会经历2次调查,国内的和德国总部的,回答各种问题,甚至配合测试实验,接下来就是等待,快的一两个月,慢的半年一年的,还看德国那边是不是也已经遇到过类似的问题了。这样的事情很少,25年也就那么几次而已,但涉及PLC,驱动,HMI都有过。
再补充一点,就是当你觉得西门子有问题的时候,我的建议是先审视一下自己是否都在技术规范之内了,而不是像那位“一串数字”小弟,拍脑袋想怎么样就怎么样的,最后就是一场闹剧贻笑大方。
请填写推广理由:
分享
只看
楼主