热线上每天都能碰到各种各样奇怪的问题，特别是有关系统诊断方面的，错误更是五花八门，这类问题往往需要查看诊断缓冲区来进行判断，但是判断的过程却是很伤神的一环，特别是当错误比较复杂的时候，今天我就来说说前几天碰到的一个。

客户：西门子工程师您好，我这有台CPU416，莫名其妙，停机了？您给解释解释？
我：是下载程序后就再也没起来还是说已经运行了一段时间，然后停的机？
客户：已经运行了一段时间，然后莫名奇妙的就起不来了。
我： 简单描述下您的配置好吗？
客户： 一台CPU，后面跟了若干卡件，有加了一条profibus DP 网络，后面跟了若干分布式I/O。
我：停机后的诊断缓冲区里可监控到哪些信息？
客户：在哪里看？
我：在硬件组态里，在线监视CPU后，双击CPU就可以在模块信息里面看到诊断缓冲区的内容了。

//如下图所示：



所有的诊断信息都可以在这里一览无遗，包括CPU的操作过程，存储卡的工作状态，OB块的组织信息，模板的故障情况等等。您可以在这里面获得大量的信息，有助于您的判断。

客户：好啊，我已经找到了，可惜很多英文我看不懂啊？
我：那也得看啊。
客户：现在情况比较急，您能帮我看看吗？我一条条读给你听怎么样？
我：一共多少条啊？
客户：100 多条呢。第一条：…
我：等会儿！！您别介！（我的妈呀，那我今天不用干别的了）那您还是给我把诊断信息发过来吧。
客户：咋发呢？
我：在诊断缓冲区的左下角，有一个‘SAVE AS’的按钮，点击他可以将诊断信息保存为记事本格式，然后发给我就行了，我帮您看看。
客户：好呀！

……邮件收到！！打开：（缓冲区内共120条信息，截取了一部分）



Event 29 of 120: Event ID 16# 4541
STOP caused by priority class system )
Event: ###1103
OB number: 1
Priority class: 1
Previous operating mode: RUN
Requested operating mode: STOP (internal)
Internal error, Incoming event
01:34:14:970 am 05/12/11


Event 30 of 120: Event ID 16# 2944
I/O access error in the nth read access (n > 1) )
P area, word access, Access address: 712
FC number: 747
Module address: 4288
OB number: 122
Priority class: 10
External error, Incoming event
01:34:14:968 am 05/12/11

….

Event 118 of 120: Event ID 16# 38C4
Distributed I/Os: station return)
Address of the affected DP slave: station number: 19
DP master system ID: 1
Log. base address of the DP slave: Input address: 8160
Log. base address of the DP master: 16380
OB number: 86
OB not found, or disabled, or cannot be started in the in the current operating mode
External error, Outgoing event
01:34:12:218 am 05/12/11



通过 Event29 可以看出，CPU停机是由OB1的优先级错误而引发的。这是什么原因呢？
咱们往前翻，通过Event30 的描述，I/O访问错误OB122被调用，而且前面有一大堆OB122的调用（篇幅有限，我只列出了Event 30，其实前面还有很多）。OB122里面有一些处理机制，由于大量的调用OB122导致OB1的执行机会非常有限（OB1的优先级是最低的），所以导致OB1的处理周期过长，超过了看门狗时间，从而致使PLC停机。看门狗时间的设置如下图所示。




大量OB122的调用是因为I/O访问错误，出事地点是在FC747的调用过程中使用了PIW712，（从Event30中得知）而PIW712是一个非法的I/O访问。PIW712好好的怎么就成了非法访问呢？咱们再往前翻。

在Event118中我们发现了OB86的影子，OB86表示的是一个分布式I/O模块从站故障。在本例中代表的就是一个I/O从站掉站了。

这时我们把问题再从头到尾捋一下：由于一个I/O 从站掉站，导致PIW712有名无实，而PIW712在程序中被大量使用，因此造成OB122的反复启用，由于OB122内容不菲，所以OB1被挤得没了机会，执行周期大幅加长，所以看门狗同志不高兴了，最终导致PLC停机。

问题是找出来了，如何解决呢，当然如果远程I/O不掉站是最好的，但是即使掉站了也不希望由此导致CPU停机，该怎样处理呢？
由于最终停机是由看门狗超时导致的。所以可以在OB122中使用SFC43 RE_TRIGR 来重置看门狗时间，这样CPU就不会因此停机了。

以上就是一个诊断的特例，希望对大家有帮助。