一个真实的完整西门子 s7-1200 S7通讯非常规故障的检查及解决案例分享(篇幅较长，请耐心看完)
本期内容来自群内网友投稿，一个真实的S7通讯故障处理及解决过程，Zui终问题也比较少见，群友希望将处理过程发出，让大家遇到类似问题时候可以少走些弯路。
01 问题描述
现场两台西门子 S7-1200PLC通过S7单边通讯实现CPU与CPU之间的数据交换，产线开机前已对通讯进行测试，一切正常，并在程序中加入了断线报警功能（通过心跳检测报通讯是否正常，数据超过10秒没有被复位则判断通讯中断），随后导入生产；连续稳定运行1个月后，突然收到生产人员反馈，两条线HMI经常报警通讯故障，频率很高，严重影响生产；就开始了问题检查处理；
心跳报警程序 HMI报警截图
02 系统架构说明
系统架构
| 产线A | IP 地址 | 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 DeviceConfiguration分别对系统内所有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不是真实的状态，可能在这个过程中发生了错误，错误代码一闪而过(可能是一个扫描周期)在TIAportal中监控不到(有1.5语了)
- 建议在程序中增加一段错误追踪程序，即检测到错误代码后，把当前状态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固件升级，问题解决；
问题解决后通讯链接