加入收藏 在线留言 联系我们
关注微信
手机扫一扫 立刻联系商家
全国服务热线18475208684
公司新闻
一个真实的完整西门子 s7-1200 S7通讯非常规故障的检查及解决案例分享(篇幅较长,请耐心看完)
发布时间: 2024-09-06 22:10 更新时间: 2024-09-16 08:00
观看一个真实的完整西门子 s7-1200 S7通讯非常规故障的检查及解决案例分享(篇幅较长,请耐心看完)视频

本期内容来自群内网友投稿,一个真实的S7通讯故障处理及解决过程,Zui终问题也比较少见,因此群友希望将处理过程发出,让大家遇到类似问题时候可以少走些弯路。

01 问题描述

现场两台西门子 S7-1200 PLC通过S7单边通讯实现CPU与CPU之间的数据交换,产线开机前已对通讯进行测试,一切正常,并在程序中加入了断线报警功能(通过心跳检测报通讯是否正常,数据超过10秒没有被复位则判断通讯中断),随后导入生产;连续稳定运行1个月后,突然收到生产人员反馈,两条线HMI经常报警通讯故障,而且频率很高,严重影响生产;然后就开始了问题检查处理;

图片心跳报警程序图片HMI报警截图

02 系统架构说明

系统架构


产线AIP 地址1214CPU + 9个  Smart 200 PN站 + 3 个 威纶通 CMT系列HMI;
PLC_A IP192.168.3.10S7客户端,发起S7通讯
HMI1_IP192.168.3.14实际也是S7客户端,占用S7链接资源,主动链接
HMI2_IP192.168.315实际也是S7客户端,占用S7链接资源,主动链接
HMI3_IP192.168.3.16实际也是S7客户端,占用S7链接资源,主动链接
PN站 IP
PN通讯无故障,此处不在赘述

图片A线硬件组态

产线B线IP 地址1214CPU + 9个  Smart 200 PN站 + 3 个 威纶通 CMT系列HMI;
PLC_A IP192.168.3.20S7服务端,被动链接
HMI1_IP192.168.3.24实际也是S7客户端,占用S7链接资源,主动链接
HMI2_IP192.168.3.25实际也是S7客户端,占用S7链接资源,主动链接
HMI3_IP192.168.3.26实际也是S7客户端,占用S7链接资源,主动链接
PN站 IP
PN通讯无故障,此处不在赘述

图片B线硬件组态


03 问题分析 & 排除

在收到现场反馈后,立马着手开始问题分析,抓紧解决问题。因为是偶发情况,第一时间链接电脑并没有发现问题;

判断1

根据情况描述,第一感觉是有IP冲突,毕竟已经连续运行1个月没有问题;突然间断性出现通讯故障,IP冲突可能较大;

检查方法:

  1. 使用“Ping”命令,对PLC_A 和 PLC_B分别进行 IP 测试;发现ping命令均正常,且经过长时间测试,一直没有中断过,测试速率也很快;

    图片Ping IP 测试
  2. 使用 IP 扫描工具 IPScaner 及 Ethernet Device Configuration分别对系统内所有IP设备进行扫描,结果也都正常,并没有出现重复或者无法扫描到的;

    图片IP 扫描工具扫描

结论:上述两种方法都确定没有问题,IP冲突引起异常排除;

判断2:

排除IP冲突后,感到问题可能有点麻烦了,然后开始怀疑PLC_A(客户端)中的S7通讯程序PUT、GET指令,参数设置是否有问题,随进行参数及程序检查;(实际内心觉得这里出问题的概率很小,要不然不会稳定运行那么久)

检查内容:

  1. PLC_A中组态链接中伙伴地址,TASP是否正确(非同一项目中的两套程序)

    图片A线链接组态图片A线链接TASP
  2. 检查PUT、GET触发条件,发送及接收地址,背景DB是否重用

    图片Get命令图片PUT 命令
  3. 检查CPU属性设置中,是否勾选允许来自远程的PUT,GET ,这一项基本上可以肯定已经勾选了,否则一开始就通讯不上;

    图片A线链接机制图片B线链接机制

结论:以上3点检查完成,果然如之前所料,并没有异常;

判断3: 事情到了这一步,确实是有点棘手了。由于产线已经是生产状态,所以无法进行停机更换网线或者交换机了,并且通过上面测试,网络应该是正常的,跟网线及交换机应该问题不大。判断程序应该执行过程中还是有错误了;

检查方法:

没有办法只能盯着程序看通讯状态了(好在通讯异常的情况挺频繁),这一来还真发现问题了!每次通讯故障,PUT/GET命令状态同时进入16#19(已开始通信,作业正在处理。)保持不变,也没有错误状态,然后持续60多秒后自动复位(心跳程序中有计时),很明显通讯程序出现了问题,但是不知道如何解决了。随后,打西门子热线寻求帮助,给出的检查结果如下:

  1. 指令和指令触发没有问题,配置没有问题;
  2. 持续60多秒的通讯肯定有问题,而且状态16#19不是真实的状态,可能在这个过程中发生了错误,但是错误代码一闪而过(可能是一个扫描周期)在TIA portal中监控不到(有1.5语了)
  3. 建议在程序中增加一段错误追踪程序,即检测到错误代码后,把当前状态MOVE到另外一个寄存器,就可以看到状态代码了;

按照西门子客服的建议,增加了错误捕获程序,继续跟进问题

图片错误捕获程序

结论:本以为这次终于能够发现问题了,结果等了一上午,报警倒是不少,但是错误一个没抓到,真正的问题还是没有找到,只能继续跟进;

判断4: 现在开始,着实有点崩溃了;这么长时间依然没有找到问题,剩下的只能是瞎猫碰死耗子了,东搞搞,西看看了;突然灵光一现,这么长时间了,一直在找客户端的问题,会不会服务端有问题?(因为正常S7通讯服务端不需要做任何程序,所以没往哪方面想,也只能检查下在线链接状态)

检查方法:

首先查看客户端的链接状态和数量--1个S7链接 + 3 个 HMI + 1个PC在线,刚好5个,跟设计一致,运行正常;

图片A线链接状态和机制

接着检查服务端链接状态和数量,这一看就不得了了,竟然出现了20多个链接,通信链接资源也全部被占用。。如下图:

图片B线链接状态和机制图片B线链接资源使用情况

结论:通过上面的分析,基本可以断定问题根源--由于B线产生了过多的链接,造成通讯链接全部被占用,A线发起的S7链接出现网络阻塞,导致通讯时间过长,甚至无法通道;终于长出了一口气,搞自控的不怕有问题,就怕问题不知道哪里来的;

04 问题解决

经过的上面的排查,Zui终问题定位到了B线PLC通讯链接上面,问题无非是CPU问题或触摸屏问题。通过将触摸屏网线断开,发现问题依然存在,判断应该是CPU有问题。

于是,将相关信息提交给西门子技术支持,西门子技术支持认可了判断结果,给出的建议是先对CPU进行恢复出厂或者升级固件版本,如果都不行则需要更换该CPU返厂检查;

Zui终,通过同厂内沟通,停下生产,进行了一次CPU固件升级,问题解决;

图片问题解决后通讯链接


联系方式

  • 电  话:13922889745
  • 经理:向小姐
  • 手  机:18475208684
  • 微  信:18475208684