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

最新更新：

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

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

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

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

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

     对于前面所得出的结论，可以看出理解和掌握通信基础理论的重要性，通过查看报文即可知其通信行为，这一点非常重要，尤其在解决现场出现的疑难杂症时，通过这些理论进行分析，可以快速的找到问题的原因。而我们所掌握的这些概念、理论、知识，都应如晨钟暮鼓时刻记忆在脑海中，应用我们的实际工作中。

     继续前面的测试，这时快速连续更改画面上的变量。响应时间按照PLC的循环周期进行，这就是通信发生在CCP上的最佳证明。

     有意思的事情就是使用键盘在连续快速的修改画面上的变量1和0之间变换时，Wireshark并没有展现在修改后立刻发送写请求，因为只有上一次写任务的响应回复，才有下一次的写请求。所以在你修改变量多次后，即停止写入后，通过Wireshark会看到每隔5秒会依次出现写请求的报文，直到写任务全部结束。此外写的次数不会丢，在我尽力快速的手速下进行的，这当然也取决于CPU的循环周期。这说明这些写任务会在WinCC中堆栈中保存。直到写响应出现，才发出下一次写请求。

     此外通过测试发现，在Wireshark的写请求任务中，每次测试都会在出现多次写任务出现后中间的某个位置必然要出现一个读请求任务，接着直到所有的写任务执行完毕才执行读任务。而如果没有写任务的时候，读任务是按照CPU的循环周期每隔5s进行响应的，那么当出现大量的写任务后，读任务的时间间隔远远大于正常的15s，那么为什么读任务会被延迟？

     这里说明一个问题就是写任务是具有优先级的，比读任务优先。这时再看WinCC和PLC通信连接的属性中是有“写优先”选项的，没有选择该选项和使能该功能的区别是什么呢？

     那么使能该选项，连续快速的按照前面描述的方式进行修改该变量，查看Wireshark中的结果。发现当激活“写优先”，在不断地修改WinCC上画面的数值时，写任务会在WinCC中堆栈排队，直到所有的写任务结束，才会产生新的读任务。这就是WinCC中的“写优先”的意义，站在WinCC的角度是对的。那么在没有激活“写优先”时，通过实验发现，无论创造出多少个写任务，此时，WinCC会分两批发送任务堆栈中的写任务。即Read var – Write var – Read var – Write var – Read var，也就是说在所有的写任务总必然会插入一个读任务。这说明无论使能该选项与否，写任务默认是优先的。两者唯一的差别就是中间是否存在一个读任务。

     为了能够更直观的理解，我画了一张图供大家参考理解。左侧是没有激活写优先，当出现多个写优先的任务（黄色箭头表示）时，读任务（橙色箭头表示）会被延迟，而且只能出现在写任务中一次，最终出现在WinCC的任务堆栈的样子；右侧则表示激活写优先中的WinCC的任务堆栈。

     至此，关于任务这个概念无论是写还是读，以及它们的工作机制和通信行为都有了清晰的认识和总结。然而，这里仅仅使用一个画面变量，那么多个画面变量结论又是怎样的呢？

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

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

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