一起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 通讯模块从站一直没有报警？这应该是我在后期必须跟踪、排查的主要对象。

谢谢W工的分享，及时掌握最新应用资讯是紧跟电气控制时代的必要手段，非常认同

是的。

   尤其在目前这样的环境下，模块更新后的特性变化，无论从硬件及软件上都会有区别。

我这起事例，刚刚是掉在这些区别上，通过主站、从站的监控才知道有这么一会事情。

我记得前几天在论坛上，季侠提出来一个200 smart cpu版本在V2.04的，“无缘无故”多出一串I/O区域，从原来的I/O(0-32byte）到新版本的（0-1151byte），这个“问题”我后来在V2.4版本软件帮助中找到答案。

当然，事前来理解模块中一些细小的改变，确实很难，也不容易记忆，只能是遇到问题了再查找文档，可能就在文档的某一页，平时并不显眼的位置，有一段对此问题非常有帮助的文字，静静的等待你去看它呢。

是呀，遇到问题思维要开阔，知识储备要充裕才能信手拈来

我理解的思维开阔，在实际应用上且往往很容易手足无措。

为什么呢？因为缺少必要的经历呀。只能是经历过了，哪怕是时间久远了，多少会有一些记忆。

真如，我贴子前面说的报警图片，一大堆报警号，从哪里开始分析呢，这个是关键性问题，所以，我特别强调了看报警的过程及方法，这仅仅只是我个人的观点，或许，还有更好的方法。

我有一个困扰了差不多半年的处理840D系统的故障问题，贴子都改写了几个，为什么没有发帖？这个问题非常蹊跷，故障排除后，可能好一个月或者几周后故障重现，所以，我反复写，总以为本次的排除故障的真正原因，但是，实际验证过一段时间后故障依然。没有真正找到更本问题是因数第一，时间拉长第二个因数是备件的供货周期实在是太过于漫长，个别的备件差不多需要一年的订货周期，着实让人心焦，有时候没有备件真的也无从下手了。

庆幸的是这次排除差不多又一个多月过去了，故障还没有重现，以至于我慢慢养成上班后必须到现场去看看的习惯，有时候，排除故障真的有点折磨人的心智。

 感谢分享。

 Profibus DP这个故障需要认真仔细，特别是偶发的情况，要大胆心细，我以前不明白的时候还用手机录像，现在回去看看还真能找到故障点。

W工真知灼见，谢谢分享！

真正把设备维护工作做好没有点真技能是做不来的

如通讯故障确实不好处理，EMC，敷设走向，现场干扰等等不一而足，但碰到很多次并用知识加以解决，理论+实践如此反复才能增加解决现场问题的本领，并留下深刻的印象及对知识的理解程度

互相之间的专题话题交流可以在一定层面上，提升自己现场分析能力。

遇到意外，一下子将手里存货干光，备件订货周期又长，各种防范措施的筹划，盼着备件到货确实心焦，真印了老话，家有余粮心不慌。

谢谢大神的分享！

@启善，话说这个余粮，有时候可把我揪心的，哎，一直说未雨绸缪，但是，事实往往存在一定的差距。

可能是我个人的认识问题，目前尤其是那些境外配件，一般订货周期都很长，现状又不清楚那些配件必须配齐，元器件的使用寿命也是通过工作后才可以总结的到。而公司如果停用设备一天你试试，其它不说，电话接的一定会让你上火，不是张三就是李四，同样一个情况反复的问你，已经给设备折磨的够呛了你的，有时候心里的无名之火确实想爆发出来、、、、、、

储粮大户，不慌

这种DP总线故障，有的还真的是很难搞所以源，我这边的2005年的进口设备，原始程序就下载了OB82,85,120。122等相关防止CPU停机的空的程序块，另外一台喂料机没有下载这类组织块后出现了停机问题，最终还是下载了OB122等后正常运行了。

王工辛苦了，图文并茂，总结的很详细啊，我一般碰到的DP通讯问题，多数就是DP头，DP电缆问题。此外就是程序设计的不是很合理造成内部停机问题。

黄工好！

   到目前为止我还没有得到德国方面为什么在OB82/86里面调用FC5（plcstop）的解释，可能他们不便解释吧。这个我也无法跟踪到底，到时候有机会当面问问。

   黄工，你讲的非常正确。在早前，我曾经也遇到过类似的情况，当通讯出现问题，联动信号丢失了，整线设备就无法联动的情况，后来是在各plc程序中弥补了这个问题的。

   总之，当通讯故障时，处理通讯硬件、连接的可靠性是必须外，主站、从站的控制程序上也需要排查。

谢谢分享，很实用。