SIEMENS西门子福建省莆田市（授权）伺服电机一级代理商——西门子华南总代理

写在前面:之前做过一次1200的s7通讯,当时一方面是时间比较紧迫,另一方面也确实没有用过s7通讯;在甲方的催促下匆忙的进行了程序调试;并未进行诸多的现场的各种可能性试验,草草的就交了工.一直没有接到甲方的程序故障,及其他的故障反馈.还沾沾自喜的认为s7-1200的s7通讯用的比较好.今年又一个项目用到了siemenss7-1200 s7通讯,下面分享下.

项目的简单描述:项目使用的硬件就不进行详细描述了,项目中共用到3块plccpu模块 (1ge31v3.2两块,1bg31为之前项目s7通讯使用;1bg40v4.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比较类似，管脚举例使用的是手写中管脚，tiav13打开太慢了--!）

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

结语：对于s7通讯来说，还是处于初学阶段，而且plc程序经常进入java思维，可能s7协议使用的就不规范，仅以此希望对那些刚刚接触s7的人能有一点帮助，足矣！