专家大讲堂《PLC通信原理探秘》系列视频：https://www.ad.siemens.com.cn/service/elearning/series/288.html

最新更新：

连载之二十二： 【PLC通信原理探秘】大讲堂幕后彩蛋之新敌

连载之二十三： 【PLC通信原理探秘】大讲堂幕后彩蛋之老生

连载之二十四： 【PLC通信原理探秘】大讲堂幕后彩蛋之常谈

连载之二十五： 【PLC通信原理探秘】大讲堂幕后彩蛋之征程

连载之二十六： 【PLC通信原理探秘】大讲堂幕后彩蛋之风云

     掌握和理解PLC的时间片和CCP通信，对于测试WinCC和S7 PLC之间的通信性能，是事半功倍的。因为对于PLC一方，那里已经没有秘密了，剩下的WinCC一方只需要根据以前的实验和结果去推测，应该不会很难。

     通过Wireshark抓包，可以看见前面实验的测试结果。序列7，由WinCC向PLC发送请求任务-读数据，在大约3秒钟左右，PLC发送读响应-序列13。中间间隔了3秒钟左右的响应时间是那么原因？与画面周期的2秒有关，还是CPU的循环周期5秒相关？序列23，由WinCC向PLC发送的请求任务-写数据，经过大约4.4秒，序列34做出该任务的响应。 这4.4秒应该对应了PLC的循环周期？然后序列36重新再次由WinCC向PLC发送请求任务-读数据，在大约5秒钟左右，PLC发送读响应-序列46。5秒钟左右的响应时间似乎与PLC循环周期的5秒对应。然而这些时间其实都是无法有根据的判断的。

     时间还是时间！判断这个问题的关键还是时间！回过头再看，发现序列13，34，46之间的时间差异值是5s，这个时间很精确，这与CPU的循环周期完全一致。那么同前面的PUT/GET Server测试的结果一样，这也意味着CPU的通信响应发生在CCP。而且这里面看报文还透漏一个信息就是Job，也就是帮助文件里面说的 “任务” ，这样就似乎清晰了很多，现在从这里看是CPU的每个周期处理都在处理一个任务，这就能理解帮助文件中提到的禁用循环模式时，一个周期只能处理一个任务。

     此外，从报文里还能看出在这个条件“禁用by PLC”，WinCC和PLC之间的通信方式无论读还是写，都是WinCC发送任务请求，PLC给予任务响应。这样在回过来看报文中的响应时间，3s，4.4s，5s这就好理解了，请求来，一个周期内给予响应。

     这样上述的结论相对来说很清晰，不过这个实验中是PLC的循环周期>WinCC的变量周期，那么再看看PLC的循环周期<WinCC的变量周期时的情况是如何的。PLC的循环周期5秒保持不变，修改画面的变量周期为10秒。序列16，由WinCC向PLC发送请求任务-读数据，在大约4秒钟左右，PLC发送读响应-序列21。序列62和序列69是同样的表现。而序列69和序列21的时间间隔是15秒左右，这是PLC的循环周期5秒与WinCC的变量周期10秒的和！？

      没有看错吧？没有。也就是说目前的测试结果的结论就是在当WinCC的变量周期小于PLC的周期时，基本上按照PLC的扫描周期进行变量的响应。大于PLC周期时，按照PLC的扫描周期与变量的扫描周期的时间和进行变量请求响应。这些仅仅是开始，想必还有更大的挑战在前面等着我。

----------未完待续----------

连载之二十八： 【PLC通信原理探秘】大讲堂幕后彩蛋之晨钟

连   载   汇  总:   【PLC通信原理探秘】系列连载故事汇总