1. 项目基本信息
Basic Project Information
锻压行业、CPU1516、WINCC、ET200SP、ET200MP 2. 问题描述
Problem Description
故障现象:循环中断属性中选择
过载事件将在诊断缓冲区中留下一次记录、启动时间错误
在CPU诊断缓冲区出现大量的事件缓冲区溢出和超过所允许的未决OB36事件数。 3. 问题分析
Problem Analysis
1) 超过所允许的未决OB36事件数,启动OB80。
调用OB80,触发了看门狗的程序。肯定是OB的运行时间超过了调用周期的时间。
针对这个问题:
做了以下测试,使用RT_INFO指令,读取OB36的运行时间,发现OB36的运行时间不超过6ms,而我设置的调用时间是10ms,当时感觉就有点纳闷,没超过调用时间,为什么会出现启动OB80的故障呢。
又仔细的看了一下手册,发现了RT_INFO,有一段话:
OB 的运行时间定义为 CPU 处理此 OB 的命令的时间段。因此不包含处理更高优先级 OB 和可能中断 OB 的通信任务所需的时间。因此,如果想要确定从处理 OB 的第一个命令到处理 OB 的最后一个命令(表示包括处理更高优先级 OB 和可能中断 OB 的通信任务)之间所用的完整时间段,请使用指令“RUNTIME”。
才明白在这种情况下,使用RT_INFO,测试的时间是不准的。
接着使用“RUNTIME”指令,进行了测量,此时发现OB36运行的时间确实超过了调用时间。
因为项目中还有别的高优先级的定时中断,所以索性把其他高优先级的循环中断都屏蔽掉,只剩下OB36一个高优先级的中断。
令人崩溃的是:还会出现事件缓冲区溢出和超过所允许的未决OB36事件数的故障。
为了进一步验证这个故障,OB36选择了Event_Count这个变量(此变量只有在优化的OB中才出现),通过程序读出其数值。
通过Trace功能监控,确实发现了出现很多的丢弃事件。
丢弃事件肯定是有高优先级的中断才会出现。但是我这个项目里没有比OB36更高的中断了。
到这时候,我就有点蒙圈了,到底是怎么回事。
既然被高优先级的中断被打断,索性我就把OB36的中断优先级提高,直接提高到19。
提高到19,故障就消失了,看来确实是高优先级的中断打断了OB36。
接着我一步一步降低OB36的优先级,直到降到14,故障又出现了。
只要是优先级大于等于15,就不出现这个故障。
测试到这一步,突然想到通讯的优先级是15,基本断定OB36被通讯打断的。
而我这个项目中的通讯只有三个Profinet、Wincc、还有电脑Portal软件在线监控。
1:排除Profinet,Profinet的刷新在程序的最开始进行刷新的,也就是说刷新完了以后才进行OB的执行。见下图