找资料时,看到了这个技术资料,很不错,和大家分享下。
项目的简单描述:项目使用的硬件就不进行详细描述了,项目中共用到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’请求!然后进行了被请求者断电、发起者断电、已经其他的现场可能出现的状况。