恭喜,你发布的帖子
发布于 2019-09-18 09:12:34
35楼
跟你说两个事实:1、相邻的另一条生产线,投产6年,PROFIBUS-DP,ABB的ACS800+SIEMENS 的DCM,交流电机最大电机功率1200KW。1.5M的波特率,一ns掉网的事故也没发生。
2、换下来的DCM已经确认PROFIBUS-DP通讯口有毛病了。
再跟你说两个常识:1、“波特率只与距离及介质有关,与干扰无关。与你是否用了变频器一毛钱关系也没有”这个结论应该是你接触PROFIUBS-DP的第一天就应该知道的,只要你认真读过有关PROFIBUS-DP的使用说明。当然,你也猜对了,这个结论肯定是从实验室得出来的。
2、PROFIBUS-DP被吐槽,正是因为你这样本就不懂它却又装做很懂的人太多了导致的。不但不懂,还否定那些EMC规范,多么的可笑。
当然,PROFIBUS-DP肯定会被淘汰,正如你所说,西家现在也是主推PN,但是,这是技术进步的体现,而不是因为一个“DP不稳定”就去淘汰它。相比DP,PN可以轻松的100M,可以更大的数据量交换,可以做1ms级的IRT,可以一种介质同时跑多种协议,可以更好降低成本……这些都是DP所达不到的。但是,你敢说你用PN时可以不遵循EMC规范?可以闭着眼睛瞎布线?
很好的帖子,可以和版主对一些观点进行辩论探讨,在探讨的过程中难免有些言辞不妥当,对于老兵版主或者以前其他的版主也不要放在心上,权当技术交流即可。
首先我要申明一下,一些版主或技术大能总喜欢非黑即白,张冠李戴。比如我说我并不认同凡事讲EMC,讲布线符合规范然后就可以推导出我不懂EMC,可以闭着眼睛瞎布线?对于这种推论想想就可笑,可以说我不懂EMC,因为你很懂EMC,你可以比我高级。。。但是你说我认为可以闭着眼睛瞎布线,那么你可以 截张图来证明我说过可以闭着眼睛瞎布线!非黑即白在技术探讨中不可取,在工控中也更不可取,并不是说某个数不是1那就是0了!
下面探讨一下我和老兵版主的两个主要不同观点:
1.我方观点:我认为1.5M的速度太高了,当出现瞬断的情况下为了稳定降低一下速率能够稳定很多,特别是在有变频器的情况下。同等条件下500K比1.5M的稳定性高,特别是在变频器的干扰下,1.5M偶尔出现瞬断的现象,降到500K你会发现偶发的现象会少很多。
老兵版主观点:波特率只与距离及介质有关,与干扰无关。与你是否用了变频器一毛钱关系也没有。当然,你也猜对了,这个结论肯定是从实验室得出来的。
同等条件下500K比1.5M的稳定性高对比波特率只与距离及介质有关,与干扰无关。与你是否用了变频器一毛钱关系也没有。可谓是两种鲜明的对比,到底是版主拿书大我令人信服呢,还是实际拿出数据来打我脸令人信服呢??我觉得最好拿实际的数据来打我脸,打得我啪啪响令人信服,也令我信服。要拿实际数据从我这边拿难免有失公允,刚好老兵版主那有一个有问题的DCM可以用来测试,还请老兵版主用测试数据来进行打脸!
测试方法如下:DP从站就是只有这一台有问题的DCM,通过上升沿记录DP瞬断的次数以及瞬断最长的时间,时长24小时。测试波特率顺序:1.5M-500K-187.5K-3M。老兵如果能把这4组不同波特率对DP瞬断及瞬断最长时间的影响数据摆上来,瞬断次数500K不能比1.5M减少30%以上,算我输,老兵版主可以把我的脸打得啪啪响。当然还有一种可能就是测试24小时1.5M的瞬断次数少于100次或者甚至没有瞬断,那么就洗洗睡吧~~
2.我方观点:DP中断程序处理很重要,不管有没有发生瞬断,在程序中也必须添加相关的处理程序,能够解决大部分瞬断问题。
老兵版主观点:用程序来克服掉网的缺陷,也只是在有限的工艺条件下可用,对大多数的工艺现场,秒以上的断网已经可能会导致事故发生了。
也有部分网友认为至于在程序中去处理就更不妥了。
在这里我简单论述一下程序处理的重要性:就举老兵版主这个瞬断的例子,里面带有多台的ACS800和DCM,假设我程序中并没有做任何处理,在运行的过程中ACS800出现了通讯中断,那么这个时候你ACS800是运行呢还是停止呢??如果是停止了,那么不好意思我通讯中断后500MS又恢复了,这个时候你ACS800是运行呢还是停止呢??有些人可能立马说了,ACS800出现了通讯中断还是继续运行的,那么我又反问你了,通讯中断了,你的设备现场还在运行,中控看的却是停止的,这个时候对你的整个工艺控制是否有影响,是否容易产生安全事故?如果你说,不好意思,你说的我程序里都已经考虑过 了,已经做了相应的预案了,也有报警记录等了,那么我恭喜你,你是做了程序处理了!
从上面一个简单的例子可以看出程序的处理是多么的重要。有些网友也问过我DP的通讯程序处理该怎么处理,当时我很想回复一下我的案例的,但是事后我想想DP的设备千千万,你的程序是否就适合所有呢?我觉得不能,因此最多具体问题具体分析了。
在这里顺带提下程序的安全性,很多程序员包括一些大能总下意识的认为自己的程序没问题,或者自己的产品没问题,我很多的时候都是用一种怀疑的眼光去看问题的,如果你的程序只是按照你的预想去运行的,那么很多时候都是可以正常运行的,但是有个很关键的问题是现场的操作人员并不像你那么专业,更不会像你清楚程序里面的那么多条条道道,一个不好意思设置错参数或者其他什么的,那么就有可能出现安全事故了。有些人认为,嗯,程序我完全考虑充足了,没问题的,那么我们现在分享一个下面的程序案例:
程序案例很简单:设备的时间控制(设备T1时间段运行,T2时间段停止,然后再T1运行,T2停止反复下去)这是一个最简单的时间控制,很多程序员 认为太简单了,我随手3分钟写完程序收工。我不否认你设置T1时间2min,T2时间3min能够很正常的运行下去,但是你有没有想过当T2设置为0的时候设备是该怎么运行的呢?T2设置为0后你的程序是否有可能会运行完T1之后来个瞬断再运行一次T1呢?当你的T1设置为0之后是怎么运行的呢?当你的T1和T2都设置为0之后是怎么运行的呢?当你的T1或T2的时间设置很长会怎么样呢?是否还能够正常运行呢?
当然我想大部分的程序员还是不会犯上面程序的简单错误的,但是也是由上面程序的简单错误能够引起反思:你的程序足够安全吗?
为何我会提到上面的程序案例?这是我的一个亲身经历,当初我还是小P孩的时候,在公司里做厂内PLC程序试验检测,就看到这么一个简单的程序(不是我写的),当时我看了下程序,感觉不妥啊,这个程序如果时间设为0之后就会出问题了。果不其然,当我T1,T2时间都设置为0后,PLC柜那个中继跳得那个欢啊,就像机关枪一样哒哒哒的。还好这在厂内做程序试验时发生的,中继跳得再欢也没啥关系,但是如果是在生产使用中呢?如果现场设备是一个250KW以上的设备跳得那么欢会产生什么问题?
以前我们公司还会做厂内试验去验证一下程序是否正常可靠,现在又有多少个公司或者程序员能够有这个条件去验证你的程序是否安全可靠呢?
不要盲目相信,你可以质疑我的说法,也可以质疑我的论点,如果最终证明我的论点或说法是错误的,那么我是很乐意虚心受教的。
请填写推广理由:
分享
只看
楼主