专家大讲堂《PLC通信原理探秘》系列视频:https://www.ad.siemens.com.cn/service/elearning/series/288.html
最新更新:
连载之二十五: 【PLC通信原理探秘】大讲堂幕后彩蛋之征程
连载之二十六: 【PLC通信原理探秘】大讲堂幕后彩蛋之风云
连载之二十七: 【PLC通信原理探秘】大讲堂幕后彩蛋之再起
连载之二十八: 【PLC通信原理探秘】大讲堂幕后彩蛋之晨钟
连载之二十九: 【PLC通信原理探秘】大讲堂幕后彩蛋之暮鼓
在禁用“By PLC” 的情况下,WinCC与PLC的数据交换方式是通过WinCC发送读任务请求,PLC进行相应的读任务响应来完成的。那么当激活“By PLC”之后,会是一种什么样的情形呢?
设置PLC循环周期通过延时程序设定为5秒左右。WinCC画面仅有一个变量M0.0, 周期为画面周期2秒。(根据前面的测试方式,也可以设置成10秒)。激活“By PLC”。通过Wireshark,查看WinCC连接PLC过程,与没有激活By PLC的启动过程不同,这里增加了注册的机制。WinCC会告诉PLC要循环读的变量和刷新周期,参考序列73,接着PLC会给与应答,参考序列110,且周期性的发送数据给WinCC。
此时发现一个令我非常震惊的结果,根据序列110,258,408,PLC会自动推送Push数据给WinCC,竟然间隔时间为100秒,是PLC循环周期的20倍,通信周期非常慢。当然数据仍然是CCP发出。这就是一些客户曾经有过的苦恼,使用300PLC与WinCC通信经常慢的原因之一。
那么为什么是100秒?这个时间是从何而来,与PLC的周期时间5秒,以及变量的画面周期2秒的关系是如何呢?再次进行测试,设置PLC的周期时间为1秒。发现PLC会每隔20秒周期性发送数据到WinCC。那么这个周期时间推测为PLC的周期Tplc(秒) X变量的刷新周期Tvariable (秒) X10。经过多次测试证明该公式是正确的,然而当PLC的周期越来越小的时候,该计算出的周期时间的偏差会越来越大,所以这个公式只能作为一个参考。上述情形是一个变量,那么画面上出现多个多种周期的变量结果是如何呢?接着我在画面上设置多个多周期的变量,刷新时间依次设为250ms, 500ms,…...10s。
测试结果发现只有刷新时间较小的两个变量可以注册循环读服务,即250ms和500ms的变量,而其它周期的变量皆不能注册,这意味着两种刷新周期小的变量由PLC按照既定周期推送数据给WinCC,而不能注册的变量还是按照以前的读任务来实现数据的传输。通过手册,发现对于一个300PLC,一个WinCC的最多有2个循环读服务,最多32个! 这说明测试结果与手册的说法一致。那么当多个画面出现切换的时候,注册的循环读服务的结果会如何呢?经过测试发现当WinCC切换画面时,原来画面上的循环读服务会申请 “取消订阅” ,PLC给予响应后,根据新画面的变量周期重新建立新的循环读服务的请求。但在新的画面上依然是2个循环读服务。
还有一种情况下比较特殊,就是最小画面周期的变量如果超过368个字节,那么就会分成两个帧进行推送数据给WinCC,且同时占用2个循环读服务。其它的画面周期变量则不能使用循环读服务。
改变变量的刷新周期,只有500ms,2s,5s。那么注册的循环读任务仍然是如上说法。此时PLC的周期是1秒。所有周期都遵守前面总结的公式。例如, 5秒(0.5x1x10)(序列4,22,38,55),6秒(5+1))(序列9,29,47,……242),以及20秒(2x1x10)(序列63,173)。
此时再使能Change Driven transfer,在PLC的延时程序中,使画面上的对应变量自增1,也就是使之时刻发生变化。然而测试的结果发现,对于300PLC在该条件下没有任何作用,因为300PLC是通过CCP发送数据的,所以数据变化也不会立刻发出,只能等到CCP。
最后,通过前面的测试结果可以得出一个这样的结论,对于300PLC与WinCC通信时不建议使能“By PLC”,除非PLC的周期足够的小,否则实际上的PLC周期性推送数据给WinCC的周期时间会比较长。此外在这种条件下激活Change Driven transfer,没有意义,并不能看到所期望的数据变化才会传输的结果。
其实这个过程的分析和总结还是很容易的,就犹如探囊取物一般,这是因为我掌握了PLC通信的概念和原理以及相关的分析方法。
----------未完待续----------
连载之三十一: 【PLC通信原理探秘】大讲堂幕后彩蛋之取物
连 载 汇 总: 【PLC通信原理探秘】系列连载故事汇总