一个真实的完整西门子 s7-1200 S7通讯非常规故障的检查及解决案例分享(篇幅较长，请耐心看完)

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

01 问题描述

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

心跳报警程序HMI报警截图

02 系统架构说明

系统架构

产线AIP 地址1214CPU + 9个  Smart 200 PN站 + 3 个 威纶通 CMT系列HMI；

PLC_A IP	192.168.3.10	S7客户端，发起S7通讯
HMI1_IP	192.168.3.14	实际也是S7客户端，占用S7链接资源，主动链接
HMI2_IP	192.168.315	实际也是S7客户端，占用S7链接资源，主动链接
HMI3_IP	192.168.3.16	实际也是S7客户端，占用S7链接资源，主动链接
PN站 IP		PN通讯无故障，此处不在赘述

A线硬件组态

产线B线IP 地址1214CPU + 9个  Smart 200 PN站 + 3 个 威纶通 CMT系列HMI；

PLC_A IP	192.168.3.20	S7服务端，被动链接
HMI1_IP	192.168.3.24	实际也是S7客户端，占用S7链接资源，主动链接
HMI2_IP	192.168.3.25	实际也是S7客户端，占用S7链接资源，主动链接
HMI3_IP	192.168.3.26	实际也是S7客户端，占用S7链接资源，主动链接
PN站 IP		PN通讯无故障，此处不在赘述

B线硬件组态

03 问题分析 & 排除

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

判断1：

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

检查方法：

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

Ping IP 测试

使用 IP 扫描工具 IPScaner 及 Ethernet Device Configuration分别对系统内所有IP设备进行扫描，结果也都正常，并没有出现重复或者无法扫描到的；

IP 扫描工具扫描

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

判断2：

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

检查内容：

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

A线链接组态A线链接TASP

检查PUT、GET触发条件，发送及接收地址，背景DB是否重用

Get命令PUT 命令

检查CPU属性设置中，是否勾选允许来自远程的PUT，GET ，这一项基本上可以肯定已经勾选了，否则一开始就通讯不上；

A线链接机制B线链接机制

结论：以上3点检查完成，果然如之前所料，并没有异常；

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

检查方法：

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

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

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

错误捕获程序

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

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

检查方法：

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

A线链接状态和机制

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

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

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

04 问题解决

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

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

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

问题解决后通讯链接