Profinet通讯故障处理实例

(一）PLC系统硬件配置

该设备采用的是CPU319-3PN/DP 、ET200S分布式I/O和 CP343-1通信处理器组成的Profinet网络以及CPUCPU319-3PN/DP与EM277 、S7-200CN组成的Profibus网络。系统网络拓扑结构如下图所示，红色框中是PROFIBUS-DP网络，通过EM277与16个S7200CN  PLC通讯。绿色框中是ET200S远程IO模块，蓝色框中是CP343-1 通讯子站模块，它们与PLC进行PROFINET 通讯。


（二）现场问题描述

在实际的生产过程中，该系统的PLC偶尔出现突然进入STOP模式的故障，导致整线停机，重新启动或将拨动开关从RUN打到STOP，再打回RUN模式（暖启动），故障就会消失。该设备已经工作9年了，一直运行稳定，此种故障发生的时间和频率没有规律可寻。
（三）问题的分析与解决过程

（A）故障分析
（1）我们首先想到的是进行硬件诊断，查看诊断缓冲区记录的PLC报警信息。但是，在故障状态下查看诊断缓冲区记录如下图所示：            

我们将记录上限调整为最大值（500条），但是都是I/O访问错误。而且出错的地址并不相同。查看程序，I/O访问错误组织块OB122已存在，因此可以确定PLC的停止与此无关。但是，出错时的故障信息都被I/O访问错误给顶掉了，因此我们需要先解决I/O访问错误的问题。
（2）寻找I/O访问错误，通过查看访问地址，以及硬件组态信息，发现缓冲区所涉及到的地址为PROFIBUS网络中子站（EM277）的地址。这些子站在单个设备中，由于生产需要，没有生产的设备需断电。因此程序在寻址的时候没有找到相应硬件，从而产生报警。            

将停开的设备上电，再进行监控，发现大部分的报警信息已经不再更新了。但是，500条诊断缓冲区记录还是被一个设备的I/O错误占用着。继续用上述方法查找相关设备。最终找到了是DP 地址为28的子站，为了扩容的考虑，厂家先把其硬件组态和程序下载至PLC，但实际的硬件是不存在的。（我们DP子站实际是有15个，但组态里是16个）。因此，将该子站删除，并把相应的读取子站信息的程序屏蔽掉。如下图所示：            

至此，PLC就不会产生I/O错误，诊断缓冲区中的诊断记录也不再更新，下一步静等故障的再次来临。
（3）找到元凶，经过几天的等待，故障终于再次发生，我们第一时间进行了模块信息的读取，并查看诊断缓冲区，由于没有I/O访问错误的干扰，立即就发现了端倪。如下图所示：            

从诊断信息中可以看出：在08:06:45.068到08:36:45.402时间内（不到400ms），有一个PROFINET IO模块（站编号：3）发生了硬件插拔错误，由于程序没有OB83（硬件插拔错误中断组织块）导致CPU进入了STOP模式，随后又立即回复了正常。它的诊断地址是：8168。随后我们立即在硬件组态中找到了它。它是ET200S远程IO模块（地址为3）下面挂着的电机启动器上的电源模块PM-D，如下图所示：           


（B）故障处理
随后我们立即赶到设备现场，找到了该模块，如下图所示，先没碰PM-D电源模块，而是晃动下面的接线端子，在晃动的过程中会发现该模块SF红灯闪一下就灭，可以确定问题就出现在这里。用力按下电源模块，听见一声“咔”，再次晃动接线端子，SF红灯不再亮了。为了再次确认问题的症结是否是这里。我们又返回PLC处，查看诊断信息，刚才PM-D电源模块SF红灯闪时都有记录，并且和PLC发生故障时的诊断信息一致。至此，兵不见血刃解决问题。         

（四）经验总结

（1）遗留的问题本次的故障实际上很明显，就是PROFINET 网络中的其中一个节点发生了模块松动，从而触发硬件插拔故障，而PLC没有相应的中断组织块（OB83），导致CPU进入STOP模式。且PLC的诊断信息已经定位到了该点，只是I/O错误将该诊断信息顶掉了，给判断增加了难度。（2）改进方法因此，在做项目的时候，尽量保证PLC正常运行时不要报系统错误，虽然有相应的组织块保证CPU不至于进入STOP模式，但是会给判断其他故障带来难度。关于Profibus网络故障分析实例可以参考以前分享过的一篇文章《为了一个自控项目，我差点告老还乡》！