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

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

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

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

连载之四： 【PLC通信原理探秘】大讲堂幕后彩蛋之曙光

        初步的试验所得出的结论，让我看到一丝曙光，然而就像黎明前总是伴随着黑暗，接一下来的一系列问题让我有些不知所措。

        在使用PUT/GET编程的时候，我想每一个工程师都会读一读在线帮助或者程序手册，去了解这两个功能块如何编程，尤其故障代码的含义。而阅读手册的时候，我又顺便了解BSEND/BRECV，以及USEND/URECV，这时候我会纠结这些功能块到底有什么区别？

        按照手册，BSEND/BRECV通信要建立连接，而USEND/URECV是无需建立连接的，那么S7到底是什么妖魔鬼怪？一个协议可以随着心意变化，而不是固定的协议交换模式，这是第一个使我百思不得其解的地方。那么手册中所提到的S7协议，不是单一协议吧？也就是说BSEND/BRECV，USEND/URECV以及PUT/GET使用不同的S7协议，虽然它们都叫做S7协议。那么要如何测试呢？作为西门子的私有协议，如何找到答案呢？

        S7的PUT/GET Server侧，是不需要编写任何功能块的，而 BSEND/BRECV，以及USEND/URECV双方都是编写功能块的，那么PUT/GET Server侧不编程就可以实现通信是如何做到的呢？又是谁帮助它实现了S7的数据交换呢？

        因为300PLC手册中提到此通信发生在CCP，而此时400PLC作为客户端，编写的GET接收数据，是不是发生在时间片？因为手册中已经提到CPU循环周期的AP部分由若干时间片组成，而GET是编写在AP中的，那么400PLC中的GET的通信必然发生在时间片？可以肯定吗？

        如果300PLC侧接收数据，那么400PLC侧需要使用PUT指令来发送数据，在Wireshark中所看见的就是400PLC侧发出的S7报文，由300PLC接收，在300PLC内部是何时接收的，在哪里接收到的呢？如何证明300PLC是在CCP接收数据呢？那又如何证明400PLC使用PUT指令进行的通信发生在时间片呢？

        上述这些问题都是源于那个通信负荷默认20%的CPU属性这个参数，那么是针对所有该PLC的通信服务吗？根据手册，这个参数至少对于CCP产生的通信应该是无效的，尽管手册中的只言片语，通过上面的试验也可以确定CCP自成一体。那么除了AP，和CCP，CPU的整个循环周期时间就剩下PII和PIQ了。而PII和PIQ是在每一个循环周期开始刷新，用于IO数据刷新，保证数据一致性，那么20%只能作用AP吧？那它能影响哪些通信服务呢？西门子PLC推出了那么多的通信服务，例如TCP/IP，PROFINET IO等等受20%的参数控制吗？如果控制，那又如何作用呢？参数的大小调整会对通信服务产生什么样的影响呢？

        反复研读手册，手册会提到通信的地方，必然会提及数据一致性这个概念，那么数据一致性的真正意义是什么？什么时候需要注意呢？又如何注意呢？手册常常提到通信PLC可以保证具有一定的数据一致性长度，例如TCP的一致性是8K，为什么？为什么会有这样的限制？300PLC的S7通信常常会提到240字节的数据一致性，而S7 PDU也是240个字节，它们之间又有什么关联呢？

        这些统统都记到我的笔记本里，我时常想着，温习着，每天都在思考如何破解。同时我也向德国技术支持总部发邮件求助，可能由于语言和文化差异，答案往往不尽人意，仅仅是得到了一个看似一个重要的信息，PG与300CPU的数据交换是通过CCP，而与400CPU则是时间片。

        一波还未平息，一波又起，似乎知道了这个信息就是徒增烦恼罢了，或者聊胜于无。总之，我如何证明这一切呢？

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

连载之六： 【PLC通信原理探秘】大讲堂幕后彩蛋之破局

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