故事作者:雾0027

最近创作

看看TA的故事

[PROFINET通信探秘]硬件插拔错误的故障

已锁定

雾0027

  • 帖子

    44
  • 精华

    1
  • 被关注

    3

论坛等级:游侠

注册时间:2009-05-30

普通 普通 如何晋级?

[PROFINET通信探秘]硬件插拔错误的故障

7235

25

2020-12-16 23:03:32

star star star

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 通信原理探秘活动汇总帖



[PROFINET通信探秘]硬件插拔错误的故障 已锁定
编辑推荐: 关闭

请填写推广理由:

本版热门话题

网友专栏

共有3227条技术帖

相关推荐

热门标签

相关帖子推荐

guzhang

恭喜,你发布的帖子

评为精华帖!

快扫描右侧二维码晒一晒吧!

再发帖或跟帖交流2条,就能晋升VIP啦!开启更多专属权限!

top
您收到0封站内信:
×
×
信息提示
很抱歉!您所访问的页面不存在,或网址发生了变化,请稍后再试。