找资料时，看到了这个技术资料，很不错，和大家分享下。

项目的简单描述:项目使用的硬件就不进行详细描述了,项目中共用到3块PLC CPU模块 (1GE31 v3.2两块,1BG31为之前项目s7通讯使用;1BG40 v4.0一块);这个项目定义为之前项目的升级项目.今年新采购的v4.0版本cpu实际上可以理解为新增的”从站”；迅速的进行了程序编写。调试过程中问题来了：

问题1；’get’’put’指令都拿不到v4.0版本CPU的数据。

针对这个问题反复的检查’网络组态’、’get、put’指令配置，几经检查均为发现问题；期间发生过几次v4.0CPU的故障报错，故障内容通俗点讲是’错误的伙伴端口’．继续查看书册，详细的通读系统手册，仍然没有发现问题所在。身处地下室且大周末的，我们的4288客服电话也不无法接通。百无聊赖中发现了v4.0版本CPU中之前版本CPU版本中从未见到的一个复选框，如下图：

顺着箭头向下我看到了个东西：

至此问题1得到了解决，紧着了问题2来了：

    问题2；1个1BG31主动去找另一1BG31和1BG40进行s7数据交互，一点时间观察后发现数据不动了，几次在线查看程序执行状态发现：我认为是随机的出现在’put’/’get’指令间。更明白的表述是会出现’status’=0x19;这个在手册里是下面描述的：

为什么会出现这个状态呢？反复的进行了测试后发现，如果v4.0CPU突然掉电，而s7通讯主动端的CPU没有断电，问题来了，整个通讯全部卡到这里了。持续观察后总结为：s7通讯应该是单线程通讯，即，相同时间点相同端口只能执行一个通讯命令，无论是rj45口还是485口，不允许程序在相同时间相同端口执行不同的通讯命令，尽管s7基于rj45口数据交换时间短到ms级别，还是要求’顺序执行’通讯程序。手册中有这个说明：

    那好吧：执行完一次’put’或者’get’命令后使用当前功能块的’NDR(GET指令)’或者’DONE(put指令)’上升沿去触发后续的’get’或者’put’指令。如同Modbus那样一个完成去触发后面的功能块。处理完毕后问题不但没有解决，进一步模拟后发现问题2有了新的升级

    问题2+；在s7非主动发起方突然掉电后，主动发起方程序执行不会给出’NDR’或者’Done’位，尽管使用的上升沿评估通讯请求是否执行完毕，程序停留状态是’error’=false,’status’=

0x19;也就是说整个s7通讯会一直停留在这个状态。看下程序块的管脚（put与get比较类似，管脚举例使用的是手写中管脚，TIA V13打开太慢了--!）

其中是不是缺少了’reset’或者’timeout’?无奈只好个人在程序中添加了段’req’接通2s后强制复位所有的’REQ’请求！然后进行了被请求者断电、发起者断电、已经其他的现场可能出现的状况。