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

最新更新：

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

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

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

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

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

     TCP的测试做了很多，从参数的理解到通信负荷，似乎遗忘了什么？对，那就是数据一致性，在这个故事系列中这是个老生常谈的话题了。

     分配了更多的通信负荷，然而却没有达到预期的效果。这里需要说明的是分配的通信负荷，并不能代表实际的通信负荷，例如，1500PLC默认的通信负荷是50%，然而这不意味着一定使PLC的周期时间延长2倍，因为这取决于实际的通信负荷到底是多少？如果在CPU中没有通信，那么周期时间就取决于程序时间。而如果想要探知实际的通信负荷，可以使用RT_Info功能块并联合Trace功能去查看实际发生的通信负荷。

     还是以前面的实验为例，取两个1500CPU，设置Communication Load为50%，目的就是不限制时间片上的通信。建立若干个TCP的连接，在一侧全部是TSEND，另一侧全部是TRECV，以尽可能快的频率去触发发送使能，然后使用跳转程序逐一投入发送功能块。编写RT_Info查看通信负荷的变化。前者使能了“Limit data infeed into the network”，其最大的通信负荷为36%，而后者最大的通信负荷高达44%。这说明了这个参数实际上真正限制的是CPU本身的通信负荷，前面所看到的带宽占用实际上是表象。

     在回头测试为什么分配更高的通信负荷，达不到最快的传输速度？前面测试使用最小循环周期是50ms，发送64K的数据，通过Wireshark来查看发送数据的结果。因为64K的报文篇幅巨大，这里只截取了前3个8K数据，可以看到351,371,396是前3个8K数据的第一个报文，从时间差上可以看出约为50ms，这恰恰是CPU的一个循环周期的时间。这说明对于TCP/IP通信来说，一个CPU周期只发送一个最大的一致性数据为8K。这也就证明了为什么需要大约350ms，因为64K有8个8K数据，且需要8个周期才能发送完毕。这里的结论也表明，并不是分配更高的通信负荷，通信就会有更快的速度，或者说更小的响应时间。而且这也表达出了，如果想通信的响应时间更短，需要合理的PLC通信设置。这就是TCP/IP通信数据一致性需要注意的地方。

     然而需要注意的是此时接收端的状态应该是如何？前面的测试中都没有提到接收端如何设置。但是这里有一条必须要牢记的是想让通信的响应周期更小，那么接收端接收数据的速度要足够的快，或者说要快于发送速度，又或者说接收端的CPU的周期时间小于发送端的CPU的周期时间。因为前面提到TCP通信的Buffer概念时说过，没有使能接收的话，两个Buffer会被占满，同样如果接收速度很慢，那么同样两个Buffer会被占满，自然通信的响应周期就会延长。

     至此，关于TCP通信的原理部分我想可以告一段落了，也可以看出这里用到的全部是前面研究的基本概念，例如：通信负荷和数据一致性，只有掌握这些概念才能深入的理解通信的原理。这样我就可以转战到S7，看看S7通信到底如何？

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

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

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