论坛中的很多网友都对西门子的产品非常熟悉，而且具有丰富的使用经验。常常接触西门子的产品，就一定接触过西门子TIA（全集成自动化）的概念。在TIA概念中，其中的一点就是一致的诊断。按照这个概念，西门子提供各种各样的诊断方式，例如LED指示灯，Step7在线，OB8X，使用SFC51，SFB52/SFB54等功能块，或者RSE，web，FB126，WinCC WinCC felxible 甚至使用Maintenance station等等。上述方法用于诊断PLC和分布式IO以及网络连接的状态，皆适用PROFIBUS和PROFINET（Web 仅适用PN）。
关于西门子PLC中OB组织块的使用，包含组织块的说明、编程举例，及相应的例程，可以参见下载中心的文档A0059。
特开放此专题探讨，大家可以交流一下如何使用OB8X（OB82/83/86）或者其它方式来诊断现场分布式IO的故障。
此次集中探讨将持续至6月4日，其中有突出表现的网友将获得加倍精华奖励积分；最终所有有效留帖的网友将获得加倍发帖金币；根据交流情况，会酌情赠送小礼品。
交流结束后将整理精华内容，供广大网友分享参考。
预祝大家交流愉快，收获丰富！

有人把OB82/86/122等诊断OB当作灵丹妙药，以为只要程序里有几个空的OB就可以万事大吉了，其实不然：
1.OB只是及时反应出了故障，但并不解决故障，OB允许CPU带故障运行。
2.诊断OB如OB82/86/122反映的是硬件上的故障，靠软件是解决不了的，软件的作用是尽快指向故障点，硬件的问题还是硬件解决。
3.诊断OB的产生会影响CPU的整个程序的执行速度，会影响系统的控制品质，尤其是一些带过程中断，大量运算及运动控制的高速生产线。
4.无条件的让OB去掩盖故障是一件很危险的事情，应该有应对的措施，让系统尽快的进入一种可控的安全状态。
5.西门子提出的故障诊断的概念，没有提出故障解决的概念，所以切记这不是“药”。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

小的项目 OB8X里面都是空的，停一段时间没什么问题
而对于大点的项目，有上位的，都会做网路结构图，标注每个站点的状态。
A(
L #OB85_Z23_ADDRESS
L 0 //First Address Digital Input in Byte of The Rack
==I
)
A #EventAccessErrorRead //Event on Address Reading IP
S "DB_ProfibusDiagnostic".ProfibusError.Node[10]
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

下装了空块就一定会不停机吗?

---

照抄了一段手册的描述:
You can modify the default maximum cycle time in STEP 7 (cycle monitoring time). When
this time has expired, OB 80 is called. In OB 80 you can specify how the CPU is to react to
time errors. If you do not retrigger the cycle time with SFC43, OB 80 doubles the cycle time
at the first call. In this case, the CPU goes to STOP at the second call of OB 80.
If there is no OB 80 in the CPU memory, the CPU goes to STOP.
不处理CPU也还是要停的!!!!!!
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

OB80时间出错的原因：
无论何时执行OB时出错,S7-300 CPU的操作系统将调用OB80。此类错误包括：
超出周期时间、执行OB时出现确认错误、提前了时间而使OB的启动时间被跳过、在CiR后恢复RUN模式。例如,如果在上一次调用之后发生了某一周期性中断OB的启动事件,而同一OB此时仍在执行中,则操作系统将调用OB80。如果OB80尚未编程,则CPU将转为STOP模式。可以使用SFC 39至42禁用或延迟和重新启用时间出错OB。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

下载一个PB DP项目后，在PLCSIM中选择“Execute”--->"Trigger error OB"，选择需要测试的OB，例如OB86，模拟一个站连接断开，就可以看到OB86被激活。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

L #OB86_RACKS_FLTD //将受影响的从站地址存到MD1590
T MD 1590
A(
L #OB86_EV_CLASS //根据是否等于39或38判断是新事件，还是老事件，＝39是新发生，＝38是以发生过
L B#16#39
==I
)
A(
O(
L MB 1593 //判断从站地址是否＝10－－15，属于32配电室，如果是，则置位 M1594.0
L 10
==I
)
O(
L MB 1593
L 11
==I
)
O(
L MB 1593
L 12
==I
)
O(
L MB 1593
L 13
==I
)
O(
L MB 1593
L 14
==I
)
O(
L MB 1593
L 15
==I
)
)
S M 1594.0

A(
L #OB86_EV_CLASS //如果是过去事件，则复位
L B#16#38
==I
)
R M 1594.0

此程序放在OB86里面，同时须将OB86_RACKS_FLTD数据类型改为Dword

自己写的一小段OB86程序，DP诊断的，只要理解了各个参数什么意思，可以自己编写。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

OB8X是SIEMENS公司STEP7中一系列故障诊断组织块，包括OB80(Cycle Time Fault)、OB81(Power Supply Fault)、OB82(Cycle Time Fault)、OB83(I/O Point Fault 1)、OB84(CPU Fault)、OB85(OB Not Loaded Fault)、OB85(OB Not Loaded Fault)、OB86(Loss of Rack Fault)、OB87(Communication Fault)、OB88(Abortion of Processing)。
由此可见，OB8X囊括了系统所有软硬件的故障诊断。SIEMENS公司提供了如此多的OB8X系列故障诊断OB块，难道一个项目中需要用到所有的OB8X系列故障诊断OB块吗？手动编写出较为完善的OB8X系列故障诊断OB块程序很是繁琐和费时，系统有没有提供一些模板(Templet)或快速组态工具？如果编写使用了众多的OB8X OB8X系列故障诊断OB块，会挤占用你多大的存储空间？带着这些问题，我就以自己的使用经验与大家探讨交流。
对于使用S7－400系列，属于大中型系统，特别是CPU416－2DP以上或CPU417H。这些CPU模块由于存储容量大(Work memory>2.8MB)、运算速度快、指令执行时间短(0.03ms/1000 instructions)、通讯能力强(Max.N=64connections)。由于这类系统配置通常采用PCS7，或使用了CFC工具组态一个中等规模的DCS项目（如一座钢坯加热炉、一条热轧钢铁线、一个化工车间等）。则可以利用PCS7库中CH_AI(Analog Input)、CH_AO(Analog Output)、CH_DI(Digital Input)、CH_DO(Digital Output)这几个Driver功能块驱动用户程序使用的I/O地址，编译(Compile)时再勾选上“Generate module drivers”。
之后，你会发现编译系统自动产生了OB8X系列故障诊断OB块。在产生的OB8X系列故障诊断OB块中，系统自动调用了OB_BEGIN(CPU Function Block)、OB_END(Terminate OB Function Block)、PS(Power Supply Function Block)、MOD_2(Non-diagnostic Module Check (32 Channel))、MOD_D1(Diagnostic Module Check(<=16 Channel))、SUBNET(SUBNET Function Block)、RACK(RACK Function Block)、CPU_RT(CPU Performance Block)、PO_UPDAT(Update Process Output)、CONEC(Connection Function Block)等系统诊断功能块。如果编译(Compile)了WinCC的OS项目后，系统还会自动组态好WinCC中的“Alarm Logging”、“Tag Logging”，这样CPU将过程诊断信息自动发送至WinCC的“Alarm List”列表中清晰的显示出来。
所以使用S7－400系列PCS7和CFC工具，获取系统的过程诊断信息无需手工在OB8X系列故障诊断OB块中编写程序，编译系统会自动生成所有而完善的软硬件过程诊断信息，并在WinCC中清晰的显示出来。由于编译系统自动生成的过程诊断信息项目数太多，会占用CPU很大的存储空间(约6％～8％)和CPU对诊断处理程序的执行开销，因此不适于S7－300系列配置的中小型系统。
对于S7－300系列的配置，过程诊断信息应手动在OB8X系列故障诊断OB块中编写过程诊断信息程序，且仅编写较为重要的故障诊断处理程序，对重要的Prifibus_DP I/O站点、重要的I/O模板，或I/O端口地址和影响生产全局性设备进行故障诊断处理。
总之，针对自身系统项目的软硬件资源配置和使用状况，合理而有效地编写使用过程诊断信息程序，既为我们快速分析和查找故障原因提供便利，又不过多挤占系统有限的软硬件资源。这是每个项目开发人员都必需考虑和重视的环节。
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

我同意上面的看法：
我们单位是“小麦制粉车间”用了一套西门子S7-400的系统 ，7个子站！
最初我们有OB82 等空的组织块！
有些子站出问题，设备停了一部分，这样会造成继续运行的设备损坏！

我们要求任何一个子站有问题，就全部紧急停！
所以我就把这些组织块删掉了 ！
任何一个子站有问题 ，CPU就停机 ，生产线全停！ 反而保护了设备！

所以说要不要这样的组织块，是要空组织块还是在组织块里面写点程序,都是根据我们的实际需要来的！我们只有弄清楚了这些组织块的功能！才能让他们发挥作用！
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。

我们单位是“小麦制粉车间”用了一套西门子S7-400的系统 ，7个子站！

最初我们有OB82 等空的组织块！

有些子站出问题，设备停了一部分，这样会造成继续运行的设备损坏！

"""我们要求任何一个子站有问题，就全部紧急停！

所以我就把这些组织块删掉了 ！

任何一个子站有问题 ，CPU就停机 ，生产线全停！ 反而保护了设备！
以说要不要这样的组织块，是要空组织块还是在组织块里面写点程序,都是根据我们的实际需要来的！我们只有弄清楚了这些组织块的功能！才能让他们发挥作用""""""

其实，当任何一个子站有问题 ，CPU无需停机 ，可以发出指令让生产线全停即可。 更加证明OB86的重要性，0B8X可以发挥作用的！
管理员注：本帖已被纳入此次探讨发帖整理，请点此详阅。