欢迎来到西门子工业支持中心网站!
欢迎来到西门子工业支持中心网站!
![]() |
“西家技术派”公众号拥有如下功能: 1.专家知识经验分享 2.发布技术派活动的信息 3.申请加入技术派 4.技术派支持案例分享 5.常见问题搜索 6.技术资料链接 |
专家大讲堂《PLC通信原理探秘》系列视频:https://www.ad.siemens.com.cn/service/elearning/series/288.html
最新更新:
连载之二十七: 【PLC通信原理探秘】大讲堂幕后彩蛋之再起
连载之二十八: 【PLC通信原理探秘】大讲堂幕后彩蛋之晨钟
连载之二十九: 【PLC通信原理探秘】大讲堂幕后彩蛋之暮鼓
连载之 三 十 : 【PLC通信原理探秘】大讲堂幕后彩蛋之探囊
连载之三十一: 【PLC通信原理探秘】大讲堂幕后彩蛋之取物
对于测试1500PLC与WinCC的通信过程,实际上给我带来了一些困扰,主要因为当时并没有给Wireshark装载S7COMM_PLUS.dll的动态链接库,所以很难找到对应的数据交换的报文,从而无法分析,记得当时反复测试,费力寻找,虽然找到一些端倪,但是最终还是寻求网络帮助,找到这个动态链接库。
通过在TIA Portal与WinCC建立组态通信连接,在其通信通道中,并没有任何参数可供修改,这一点与300/400PLC不同。其主要原因是通信做了优化,更主要的原因是1500PLC的性能确实强大。这也能看到一个趋势就是未来产品的使用会越来越简单,其性能的提升弥补了人为的设置。
与前面的测试方法类似,通过Wireshark抓包进行分析发现,与300/400PLC访问变量的方式是根据变量地址来寻址不同,1500PLC采用的是变量标号的方式,所以无需要求WinCC上的地址是来自同一地址区或者连续的变量,这一点与300/400PLC截然不同。在测试的结果中,可以看到变量的是带有标号的,即1,2,3……,每一个变量都是有固定的格式和长度大小。S7报文的S7PDU的大小是960B。
测试还发现,写优先的功能已经不存在了,这意味着与读任务的优先级是相同的,谁先到,先执行谁。数据通信采用订阅的方式,即PLC会根据WinCC画面上的变量刷新周期进行数据“通知”,这一点与300/400PLC在“By PLC”时,画面周期小的变量进行“注册”,然后PLC根据设定的时间进行“推送”的机制是一样的。只不过这里使用的“订阅”和“通知”的通信概念。
此外,相同的变量刷新周期的数据一起会被“通知”,但只通知变化的数据,通知数据发生在TS。这一点与300/400PLC不同的是1500PLC的数据变化不再仅局限于DB数据,因为变量不是地址寻址,而是按照标号来进行的。判断数据变化的方式与前面描述的400PLC在激活 “By PLC”&“Change Driven transfer”条件下是一致的。
有一个特殊的地方就是画面变量的刷新周期如果超过10s(含),则这些变量不参与订阅,采集数据使用“轮询”的方式,与前面描述的读任务请求和应答的方式一致。
在测试的过程中,还发现了一个有趣的现象,就是在WinCC启动的过程中,WinCC尝试与PLC建立通信,此时PLC是S7的服务器,WinCC会尝试与102端口建立连接。然而这时还会有两个连接会不断的建立连接和断开。这意味着连接资源占用和释放的过程。这也说明为什么1500PLC与WinCC建立通信是占用3个S7连接的原因吧。
到这里,我把整个探索时间片和CCP通信的过程和大家分享就结束了,希望这些研究成果能够给到大家启发和帮助,后续如果有新的发现,会和大家在第一时间分享。此外,由于很多概念和信息并不是来自手册和官方文档,可能会出现一些错误或偏差,如果给大家带来困扰,也敬请大家谅解。后面还会有最后一篇故事是我的一些个人体会和学习方法,希望能和众位网友共鸣!我们可以通过我们的网站共同探讨这些通信话题,不见不散!
----------未完待续----------
连载之三十三: 【PLC通信原理探秘】大讲堂幕后彩蛋之不散
连 载 汇 总: 【PLC通信原理探秘】系列连载故事汇总
@www123456 :3楼2020-05-20 22:15:55
记得上次用户反应设备的1500与触摸屏总是通信中断,也不知道什么原因,只知道可能是与甲方MES网络联网引起的问题,由于事先网络规划不好,MES与设备网络没有隔离,但没有任何办法证明是这个问题,因为单独哪个网络都没问题,只是连到一起才发生的,其实是由于甲方路由器安全机制起作用了,所以才想到了wireshark分析一下网络报文数据。原来用网管功能型的交换机也可以获取报文,不过价格太高了。还想到一个办法,设备前端用一个PN/PN耦合器也可以隔离网络。
Bany scope是什么工具呀?
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
一直没有注意您的这个帖子,这么晚回复,不好意思。
对于故障现象,目前来说如果隔离了,故障消除,那么原因就比较明了了。主要的原因就是办公室网络的数据影响了控制层的网络数据通信,最大的可能性就是广播负荷的增大导致的,但是广播负荷的原因可能是木马,就是说在MES网路中的问题,这只是可能性;另外就是广播的负荷影响设备的正常运行,比如第三方的驱动,品牌这里不提,出现广播的负荷增加,同样的情况ET200S就不会断网。原因就是该驱动不能集中处理大量的广播报文,说白了就是芯片的质量不高造成的。当然这些都是猜测,需要抓包去看。
看了这个案例,我觉得你可以吧这个案例分享一下,就是我们工业技术π的这个阶段的活动,加入我们的技术π直播间和PLC通信的技术π圈,这个圈子我会长期驻扎,给大家答疑解惑。
对于Bany scope是一个与XM400相配的软件,需要结合Wireshark来抓取报文,但Bany Scope可以做各种图表的,数据的,各种分析。可以登录我们的网站,查看具体的信息。
Bany scope是什么工具呀?
Wireshark与1200/1500通信确实看不出改进的S7协议报文结构,要自己添加链接库才行,报文结构与300/400的S7协议确实不同,这个链接库不知是否免费下载的?容易添加吗。
请填写推广理由: