一起profibus DP通讯故障的处理过程

   今年8月份开始着手安装的一组（几台设备组合联动）840D sl系统设备，自投运10多天运行以来一直没有什么问题。这不，越是记挂它，它越会来事情，几天前开始时不时的出现设备系统报警停机，这个报警是随机性的（事后恢复断电送电了几次的验证）。

按惯例，先上报警图片，使文档看起来连贯性强一些。

   到设备现场，看MCP面板整个3个按钮区域的LED灯全闪（丢失通讯或系统重启会是这样的状态），再看OP屏上的报警信息，图示：

好家伙，报警清单中一大篇报警显示啊，初一看怪吓人的。

已经磨励了10多年的我（一根锈铁棒，也开始磨出了一点点针尖），不会被这些报警信息吓着了。看报警必须从开始（报警列表的底部）看起，是谁引发的？有一些报警信息是某一个触发位故障，引发的一连串关联问题，处理问题的顺序需搞清楚非常重要，才能够得心应手。

428221#报警，信息提示是硬件诊断地址16344#，对应于用户程序中的硬件是DP/DP Coupler模块的诊断地址。到控制柜一看果然是这个模块出现了报警，图示：

   同时，右侧的UCN也亮起了报警红灯。

基本检查外围没有明显的线路短路和短路器过载跳闸原因后，用惯用的方法：断电再上电呗。很快系统恢复了正常，DP/DP Coupler模块在系统启动完毕后红灯消失。到操作台处启动系统控制、启动液压站，试着移动几根轴没有问题。关闭液压站，想到设备各处再看看有什么怀疑之处。不一会儿，故障再次出现。好家伙，只能回办公室拿电脑来在线诊断了，仅仅看到模块红灯是无法正确判断问题的所在。

在线，cpu诊断，图示：

诊断信息提示：模块问题或必要的维护。

再看DP/DP Coupler模块诊断信息，图示：

诊断信息提示：模块可用且正常，点击“更新”按钮，信息依旧，说明模块报警并没有问题，是最新的报警。

   到主站去看看，主站cpu会有那些提示信息，图示：

主站cpu诊断信息提示，21#从站（新840D sl设备从站号）确实存在报警，模块故障（检测到诊断中断）外部出错。

在此profibus DP网络中，有在用设备20多台一直在正常运行，其它的设备运行一直正常，唯独这台新上的840D sl系统近期多次出现通讯错误，且从DP/DP Coupler模块的红色指示灯看是SF2报警，即profibus DP总网络上存在的故障。

从上面的几张图片看，通讯故障应该出现在总profibis DP网络是一定的。但是，怎么会让新设备的840D sl系统因通讯故障而停机的呢？

返回到故障设备现场，再看具体的故障诊断信息，提示：当cpu侦测到通讯错误时，需要调用OB82这个组织块，看程序结构中确实也有这个组织块OB82的存在。打开这个组织块，看到组织的程序有调用FC5（用户自定义加密子程序）程序名称是：PLC STOP，估计实际调用的是SFC46（加密无法深究了），且调用条件是：

PlcStop = ：TRUE    //启动FC5

    难怪了，原来造成系统停机的问题在此啊，本想把这个PlcStop设置为FALSE值。考虑到设备在保内，且尚对该设备未全面了解，不敢轻易修改，以免造成不必要的麻烦。于是把信息发送给设备制造商，因为是德国设备，他们上班相当于我处地理位置的中午12点后，我重新整理了报警过程的来龙去脉，及自己的分析原因，发信息已经是傍晚了。算了，等明天看回复的邮件信息吧，今天回去正好仔细看看DP/DP Coupler模块手册。

晚上，在电脑上找到DP/DP Coupler模块快速入门手册，仔细看了看，外围接线没有问题，一度怀疑CN2的绿色电源指示灯没有亮与通讯故障可能有一些关联，因为，当初由于该设备距主站有近200米的距离，原先考虑装中继器的。由于中继器订货迟迟未到也就放弃了安装使用，改为直接连接。通过快速入门手册描述，CN2允许不连接电源。主要是新版本的DP/DP Coupler模块考虑到电源冗余系统中的应用。

重新又疏理了一遍白天设备的故障过程：当新设备的840D sl检测到通讯错误时，cpu会自动调用OB82组织块，刚好，调用时启用FC5，（PLC STOP）的子程序，使系统处在stop状态，由此，MCP控制面板上的LED指示灯闪烁也属于正常了，故障原因分析及建议停止调用FC5的确认，只能等待明天德国方面给我的信息了。

等待总是那么的漫长，等到下午（德国工程师上班后，确认过来了），主要让我排除引起这个外部通讯故障的更本原因（领教过德国工程师的执着和做事认真的劲），最后，允许我将OB82组织中的FC5 PlcStop = ：TRUE值改为FALSE（不调用FC5）。

通过邮件看到这个许可，立即到现场，将这个控制位修改了，并将此修改过程回复给德国设备制造商电气工程师那里。经过一天的观察，到目前为止因报警而停机的问题没有再次出现过（截止到我发帖之前还是正常的）。我在做类似通讯时，会调用相应的OB组织块，但是，与部分编程者一样，只是为了“欺骗”一下cpu，不至于被调用时，因cpu没有找到相应的OB组织块而停机而已。

小结：

    这起故障处理过程，主要是分析思路正确，少走了很多弯路，并严格按cpu诊断信息提示内容进行。结合主、从站的cpu诊断信息，及从站通讯故障所调用的OB82组织块展开。

   那么，可能有人会问，为什么其它的从站可以正常运行，而且且这个从站会出现通讯故障报警呢？我认为有以下几点原因：

1）  新版本的DP/DP Coupler模块兼容旧版本的所有功能外，增加了诊断中断功能（触发这起通讯故障的更本原因），旧模块没有诊断功能；

2）  新设备的程序中，OB82组织块中编辑了FC5（PlcStop）停机子程序，使系统一旦侦测到通讯故障后，进入OB82组织块，一旦调用就是停机的死循环中。（这个正在寻求德国方面给一个确切的答复，为什么要在此组织块中写这个程序的原因何在）；

3）  从站下挂的DP/DP Coupler模块报警：“模块问题或必要的维护”是指总线侧SF2侧是可以理解的，但是实际模块并没有给出报警信息，而是需要通过主站诊断来判断。也可以理解为CN1没有错误，模块就没有报警信息；

4）  从此故障现象看，并非我所管辖的profibus DP总线不存在通讯问题（20多台设备连线一直正常运行判断条件下），而是旧的那些DP/DP Coupler模块没有这个功能，总线的维护也迫在眉睫了，想一想自上次最后的降频处理过总线故障已经近10个年头时间了；

5）  通过看必要的手册，才能够充分掌握新版本模块与旧版本模块，在具体应用上的区别，才能把问题分析的更具体，及时掌握最新应用资讯是紧跟电气控制时代的必要手段；

6）  产生profibus DP通讯故障的更本原因是什么？在哪一些环节会出现？为什么在物理链路该从站的后面的几个ABB机器人和S7-1214C的DP 通讯模块从站一直没有报警？这应该是我在后期必须跟踪、排查的主要对象。