1.应用的基本信息 

     我是进行现场维护的电气人员，在实际的维护工作中，经常遇到PLC、HMI、网络等方面的问题。今天与大家分享的就是处理其中一个故障的过程。故障设备采用的是CPU319-3PN/DP 、ET200S分布式I/O和. CP 343-1通信处理器组成的profinet网络以及CPUCPU319-3PN/DP与EM277 、S7-200CN组成的profibus网络

 2.问题描述

     现场的网络拓扑结构如下图所示。红色框中是PROFIBUS-DP网络，通过EM277与16个S7200CN  PLC通讯。绿色框中是ET200S远程IO模块，蓝色框中是CP343-1 通讯子站模块，它们与PLC进行PROFINET 通讯。

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

3.问题的分解和解决

 3.1故障或问题分析

    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 DC24V

   3.2故障或问题处理

         随后我们立即赶到设备现场，找到了该模块，如下图：

     先没碰PM-D电源模块，而是晃动下面的接线端子，在晃动的过程中会发现该模块SF红灯闪一下就灭，可以确定问题就出现在这里。用力按下电源模块，听见一声“咔”，再次晃动接线端子，SF红灯不再亮了。

     为了再次确认问题的症结是否是这里。我们又返回PLC处，查看诊断信息，刚才PM-D电源模块SF红灯闪时都有记录，并且和PLC发生故障时的诊断信息一致。

     至此，兵不见血刃解决问题。

4.经验总结

4.1遗留的问题

     本次的故障实际上很明显，就是PROFINET 网络中的其中一个节点发生了模块松动，从而触发硬件插拔故障，而PLC没有相应的中断组织块（OB83），导致CPU进入STOP模式。且PLC的诊断信息已经定位到了该点，只是I/O错误将该诊断信息顶掉了。给判断增加了难度。

 4.2改进方法

因此，在做项目的时候，尽量保证PLC正常运行时不要报系统错误，虽然有相应的组织块保证CPU不至于进入STOP模式，但是会给判断其他故障带来难度。

------------------------------------------更多案例集锦汇总在活动帖中-------------------

PROFINET 通信原理探秘活动汇总帖