众所周知，Profibus及Profinet在工业现场应用非常广泛，也是西门子主导的通信方式。为了减少停机时间，提高效率，针对Profibus及Profinet的诊断，西门子推出了很多诊断方法，而其中调用相应的OB块是最基本的获取故障信息的方法。接下来的一段时间，我们就围绕着网络诊断以及OB块的调用这两者的结合点进行详细讨论，希望大家踊跃发言，谈谈应用过程中的问题及感想。

抛砖引玉，现提出如下问题供大家思考：
1.CPU在什么情况下要求调用OB82、OB85、OB86、OB122？
2.OB82和OB86分别有什么功能？它们能用于那些故障诊断？
3.怎样设置OB85的调用方式？OB85有什么作用？
4.OB122有什么作用？
5.为什么很多项目的OB82、OB85、OB86、OB122没有编任何程序？这样做有什么利弊？
6.OB82和OB86的局部变量提供了那些信息？怎样对它们编程？

活动奖励：
此次集中交流将持续至11月20日，其中所有精华帖作者将获得加倍精华奖励积分；最终所有有效留帖的网友将获得加倍发帖积分。更多积分带给您更多奖品兑换的自由。
对于有突出发言贡献的网友可获得金币奖励，可以在当前的兑换奖品中兑换奖品。
交流结束后也将专门整理重要内容，供广大网友分享参考。
预祝大家交流愉快，收获丰富！

具有诊断功能并启用了诊断中断的模块检测到错误，以及错误消失时，产生诊断中断，CPU的操作系统将自动调用处理诊断中断的组织块OB82。故障出现和消失时将分别调用一次OB82。
模块通过产生诊断中断来报告事件，例如信号模块导线断开、I/O通道的短路或过载、模拟量模块的电源故障等。OB82的启动信息（20B局部数据）提供产生故障的模块是输入模块或输出模块、模块的地址和故障的种类。通过在OB82中调用故障诊断的逻辑块（例如SFC 13），可以判断在哪个通道发生了什么样的故障。
由于通信或组态的原因，模块不存在或有故障，刷新过程映像表时I/O访问出错，CPU将会调用优先级错误组织块OB85。
如果扩展机架、DP主站系统或分布式I/O由于掉电、总线导线断开、I/O系统的故障，或者某些其他原因引起的故障，CPU的操作系统将调用OB86。故障出现和消失时将分别调用一次OB86。
CPU如果用PI/PQ区的地址访问有故障的I/O模块、不存在的或有故障的DP从站（例如断电的从站），CPU的操作系统将在每个扫描循环周期调用一次OB122。

为了保证系统的安全，最简单的方法就是不下载有关的OB，一有风吹草动，CPU罢工，一停了之。这样处理安全基本上得到保证，但是业主不高兴了。
如果下载空的OB， 编程者在设计时，一定要仔细考虑出现各种硬件故障时出现可能的后果，和应该采取的措施。首先在规划系统时应使各站点有相对的独立性，即使通信中断，也不至于产生灾难性的后果。例如PID的控制器和过程变量、输出量不要分别放在两个站点，因为通信中断时将会使PID闭环开路，被控量失控。
在故障出现和故障消失时都会调用OB86和OB82。可以在OB86和OB82的局部变量中获取调用的时间，计算同一个故障持续的时间。如果的确是“闪断”，故障可以忽略。如果持续的时间超过某一设定值，则应作相应的处理。该停机时还应果断停机。
故障处理实际上不是“骗骗系统、骗骗业主”的问题。如果因为编程时故障处理不当，造成机毁人亡，是要坐牢的！！！

对此问题个人认为有两个方面要去了解。一：要清晰的了解什么情况下系统会调用那几个OB块；二：OB块调用后如何利用。如系统调用了OB85或OB86时都提供了那些信息，这些信息该如何使用。
个人以为这些信息的充分利用才真正反映了一个自动化系统水平的高低。

前面众大侠对不同的OB给出很好的诠释和理解，也学习了很多。

是的，OB块是操作系统和用户程序的接口，能给我们（编程者）提供较多的有用的诊断信息。更重要的是：当事件发生那个时刻，操作系统就已经把控制权交到了用户程序手中！关键是，需要用户程序及时做出相应的处理，用户程序可以根据事件对生产过程的影响程度，产生报警、显示具体信息、PID自动切换到手动，由操作人员手动干预控制生产过程，直至生产过程安全和稳定；或者，即使相应的事件OB存在，必要时用户程序也可以让CPU进入STOP模式。

在一些生产工艺比较单纯、不影响产品质量或者不会发生人身、设备安全事故的场合。为保持连续生产，下载空的OB块，防止一些小问题而使CPU进入STOP，也算是：不是办法的办法······这种处理方法导致事件发生时，不能第一时间得到事件信息，需要查看CPU诊断缓冲区才能分析。

转发一个2011年在我的博客发的帖子：
根据OB86的局部变量诊断和显示有故障的PROFIBUS-DP从站
一直想编这样一个程序，用仿真调试完后，发现程序很短，有一定的实用价值。
S7-300/400的OB86的局部变量OB86_EV_CLASS（LB0）为16#39和16#38分别表示故障出现和故障消失。OB86_FLT_ID（LB1）为16#C3和16#C4分别表示DP主站系统（DP网络）故障和DP从站故障。LB10是DP主站系统的ID（网络的编号），LB11是有故障的DP从站的编号。
假设项目中只有一个DP网络，12个DP从站的编号分别为3~14，它们分别对应于M10.3~M11.6。
出现DP主站系统故障时（LW0为W#16#39C3），将M10.3~M11.6全部置为1（将W#16#F87F送MW10）。
某个DP从站出现故障时（LW0为W#16#39C4），将故障从站编号和M10.0的地址相加，计算出故障从站对应的地址，然后用间接寻址点亮故障从站对应的指示灯。
某个DP从站故障消失时（LW0为W#16#38C4），将故障从站编号和M10.0的地址相加，计算出故障从站对应的地址，然后用间接寻址熄灭故障从站对应的指示灯。
在SIMATIC管理器中生成一个人机界面的站点，双击站点中的画面1，打开WinCC flexible的项目，在画面中生成12个指示灯。它们分别通过M10.3~M11.6来显示3~14号从站的状态。
下面是OB86中的程序。
L W#16#39C3
L LW 0
==I
JCN m001 //不是主站系统故障则跳转
L W#16#F87F
T MW 10 //点亮3~14号从站的指示灯
m001: L W#16#39C4
L LW 0
==I
JCN m002 //不是从站故障出现则跳转
L LB 11 //故障从站编号送累加器1
L P#10.0 //起始地址送累加器1
+D
T LD 20 //故障从站地址送地址指针
S M [LD 20] //点亮故障从站对应的指示灯
m002: L W#16#38C4
L LW 0
==I
JCN m003 //不是从站故障消失则跳转
L LB 11 //故障从站编号送累加器1
L P#10.0 //起始地址送累加器1
+D
T LD 20 //故障从站地址送地址指针
R M [LD 20] //熄灭故障从站对应的指示灯
m003: NOP 0
使用16个字节（例如MB10~MB25），最多可以用画面上的指示灯显示120多个从站的状态。

用仿真软件学习DP从站故障诊断的方法
S7-300/400的仿真软件PLCSIM对通信功能的仿真能力较差，只能对S7通信仿真。仿真软件可以模拟某些硬件故障和网络故障，是学习网络故障诊断的好工具。
用仿真软件模拟DP从站故障的步骤如下：
1）在硬件组态中生成DP主站、DP网络和DP从站。
2）保存和编译硬件组态后，将系统数据下载到仿真PLC。将仿真CPU切换到RUN-P模式。
3）执行PLCSIM的菜单命令“执行”→“触发错误OB”→“机架故障 (OB86)”，打开“机架故障OB（86)”对话框。在“DP故障”选项卡，已组态的从站为绿色。
4）点击某个从站对应的小方框，方框内出现“X”。用单选框选中“站故障”，单击“应用”按钮。选中的从站对应的小方框中的“X”消失，小方框变为红色，表示该站出现故障。CPU视图对象上的红色SF（系统故障）LED亮，DP（总线故障）LED闪烁。
5）执行SIMATIC管理器的菜单命令“PLC”→“诊断/设置”→“硬件诊断”，打开“硬件诊断 - 快速查看”对话框（见下图），可以看到1号网络3号从站有故障。




6）双击CPU，打开CPU的模块信息对话框。在“诊断缓冲区”选项卡的“事件”列表中的事件“分布式I/O：站故障”表示3号从站出现故障。
选中该事件，在“关于事件的详细资料”窗口，可以看到要求调用OB86，外部错误，进入的事件（事件产生）。
7）双击上图中的DP从站，打开从站的模块信息对话框，可以看到从站的有关信息。