定时中断真的像你想的那样运行吗？

admin

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，主要是针对那些通讯来说的？
来源：西门子工业技术论坛