故事作者:小釉

最近创作

看看TA的故事

【夏日重燃】定时中断真的像你想的那样运行吗?

已锁定

小釉

  • 帖子

    2779
  • 精华

    26
  • 被关注

    59

论坛等级:至圣

注册时间:2011-05-12

白金 白金 如何晋级?

【夏日重燃】定时中断真的像你想的那样运行吗?

1438

9

2020-06-30 22:55:45

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的执行。见下图



2:Wincc。现场直接把和WINCC连接的电脑网线拔掉,问题还是出现。说明不是WINCC的事。

3:Portal。因为在测试的过程中,要使用Trace功能,所以一直在线。将Portal离线后,令人欣喜的事,出现了。

故障不再出现了。

为了进一步验证,查看了PLC诊断缓冲区中的信息,发现在离线的两分钟之内,都没有出现。

在线监控的时候,1s中都要出现好多次。


到此为止,原因算是找到了,通讯打断了循环中断的运行。

当然我这个项目中,还有别的高优先级的中断,通过设置OFFSET,可以避免此问题的出现。

在测试过程中,关于OFFSET的设置也有些心得。

在这里也分享给大家:offset主要是针对同优先级的中断来说的。不同优先级的OB,高优先级OB来到时,肯定要打断低优先级的OB。对于不同优先级的循环中断来说,Offset的意义在于如果同时触发时,没有offset,低优先级的被高优先级的打断,会造成排队事件,如果有了offset,到了触发时间点,通过offset错开高优先级的程序,就不会出现排队现象。触发的时间点是基于CPU的时间基准,另外offset的时间必须高于高优先级程序的运行时间,低于高优先级程序运行时间,照样会出现排队事件。

对于有些应用,如果循环中断运行的时间超过了别的循环中断的调用时间,此种情况下,PLC就无力回天了,只能选择性能更高的CPU了。

因为在运行程序的时候,还未运行完毕后,就会触发新的中断,

此时有两种情况,

1:如果触发的中断优先级比较高,那么高优先级的中断会打断正在运行的OB,造成了低优先级OB运行时间的增大,很有可能造成看门狗触发时间。所以在使用OB一定要注意,OB运行的时间要比调用时间小的多才最保险。

2:如果触发的中断的优先级低,那么就造成了排队事件,定时中断的精度就要差。如果多次排队事件出现的话,按照默认的设置,1次排队事件的话,后面的中断就会被丢弃。也就是说10ms的定时中断,有可能会出现两次调用OB的时间30或者40ms。

这个在测试过程中确实也发现了这个情况。

       

4.       总结

       1)  准确的测试OB运行时间使用RUNTIME指令,RT_INFO指令是由局限性的。

       2)  1500CPU中,OB循环采用优化的方式尽量将能选择的报警触发都选择上,这样更容易发现问题。

      原先项目中,没有选择过载事件将在诊断缓冲区中留下一次记录、启动时间错误,在CPU诊断中不出现故障信息。

     3)  1500中,如果要保证CPU的循环中断的实时性,可以将OB的优先级提高到15以上,这样可以保证不被通讯打断。

    当然这样打断通讯,还造成通讯的时间加长,这个就需要全局考虑。在300、400PLC中是不可以这样设置的。

 

 

5.      遗留问题

      问题虽然找到了,但是还有有遗留问题的。

为什么在线能够中断循环中断OB,而WINCC不能呢?

针对这个问题又做了测试,通过CPU web功能,

查看到Portal在线占用的通讯和WINCC通讯占用的资源是不一样的


前三个是WINCC占用的通讯类型HMI,后面两个事Portal在线占用的通讯类型ES。

同样是通讯,不同的通讯类型优先级也不一样?平常说的通讯的优先级15,主要是针对那些通讯来说的?




【夏日重燃】定时中断真的像你想的那样运行吗? 已锁定
编辑推荐: 关闭

请填写推广理由:

本版热门话题

网友专栏

共有3227条技术帖

相关推荐

热门标签

相关帖子推荐

guzhang

恭喜,你发布的帖子

评为精华帖!

快扫描右侧二维码晒一晒吧!

再发帖或跟帖交流2条,就能晋升VIP啦!开启更多专属权限!

top
您收到0封站内信:
×
×
信息提示
很抱歉!您所访问的页面不存在,或网址发生了变化,请稍后再试。