• 专家大讲堂《PLC通信原理探秘》系列视频：

https://www.ad.siemens.com.cn/service/elearning/series/288.html

• 最近更新：

连载之七： 【PLC通信原理探秘】大讲堂幕后彩蛋之扬帆

连载之八： 【PLC通信原理探秘】大讲堂幕后彩蛋之柳暗

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

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

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

        检测S7-300的BSEND/BRECV通信的数据一致性，通过Wireshark我能清晰的看到S7 PDU中的数据大小，如下图，这是S7数据报文的首包，其中可见Data的全部长度是206B，可以通过点击高亮整个Data部分，然后会在左下角出现数据的全部长度206B。然而通过反复测试发现，Data部分的206B并不是全部是真正的发送数据，前两个字节01E0是固定存在的，没有S7协议的相关解释。我的第一个字节是16#AA开始的。除了首个S7报文，后面的数据长度皆为206B，因为没有了01E0的2个字节的占用。

        那么数据一致性是不是204B？还是像手册中描述的240B，那么无论对于发送方还是接收方，数据处理会变得相当复杂，例如，发送方发送一致性是240B的数据，再从CPU接口发送出去的时候，要分裂成两个部分，第一个是204B，剩余36B再和剩余的数据继续合成206B，以此类推，接收方在接收到数据传送到CPU内计算前，会把第一包中的204B拿到，然后等待第二包数据，再从第二包数据中取出36B，合成240B再送至CPU的内存中，以此类推，这样的情况是相当复杂！300的CPU如果真的这样处理，那CPU的负荷一定超高，很难处理吧？！然而这些都是假设，猜想，需要去证明数据一致性到底是240B还是204B。

        如何来证明？那么再次回过头来看看数据一致性，对于通信来说，数据一致性长度的数据是一致就意味着这些数据在通信的过程中是不能被修改的，那就意味着数据一致性长度以外的数据可以在通信过程中被修改？是的，就是这样的！那问题的解决就简单了，我可以通过程序同时修改第204B和第205B，再看接收方收到的数据是否两者的数据结果是一样的。

        我在一侧发送数据480个字节，在SEND程序执行后立刻执行数据修改程序，就是数据自增1的简单程序。程序中数组序列从[0]开始，那么Data[203]就是第204字节，Data[204]就是第205字节，两者在初始的时候都为0，那么自增程序从结果上去看两者的数据是一样的。

        接收方收到数据会看到Data[203]=0，而Data[204]为一个随机的数，这说明数据发送的时候，前面的204B数据已经被封装，后续的数据任何修改都不会对它产生影响，而第205个字节，因为没有数据一致性的保护，那么它会在第一包数据封装的时候仍然会被修改。这就证明了S7-300通信的首包数据一致性的长度是204个字节，后续的自然是206个字节。接着我还是在接收方使用延时程序，使接收变慢，这样会看到接收数据的长度在不断地变化204à410à616à……（如果发送长度很大的话）。如果不是用延迟程序，其实通过程序也可以把长度的变化过程截取出来。

        数据一致性的概念，无论是在CPU内部的程序处理，还是通信的数据一致性长度，现在都已经澄清完毕了。那个时候，真是鼓舞的时刻，你会大喊：“还有谁”！

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

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

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

有帮助(14)