1.应用的基本信息 

   项目中应用1台 CPU 414-3 PN/DP V7.0版本,2个ET200M和1个ET200SP从站，两台上位机WINCC7.4SP1。通讯方式由原先的Profibus改为Profinet。ET200M改为ET200MP，ET200S改为ET200SP,PLC 使用CPU1516替换原先的CPU 414-3 PN/DP V7.0

2.问题描述

   当使用监控软件PLC-ANALYZER pro 5 采集数据时，设备动作频次明显降低。

 3.问题的分解和解决

 3.1 故障或问题分析

       动作频次降低，从原理上分析，肯定是CPU刷新动作的频率降低了，但是在程序中所有相关动作都是使用定时中断程序来执行的。理论上应该不存在运算降低的问题，除非定时中断被丢弃了或者被打断了。

 3.2故障或问题处理

       为了验证这个想法，在10ms定时中断中加了一个加1指令，每次定时中断运行的时候都加1，通过2ms的Trace采集信号。

     通过上图发现，最多的时候循环中断会被丢弃3次。并且频率很高。

    丢弃事件肯定是有高优先级的中断才会出现。但是项目里没有比OB36更高的中断了。

    既然被高优先级的中断被打断，索性我就把OB36的中断优先级提高，直接提高到19。

    提高到19，故障就消失了，看来确实是高优先级的中断打断了OB36。

    接着我一步一步降低OB36的优先级，直到降到14，故障又出现了。

    只要是优先级大于等于15，就不出现这个故障。

    测试到这一步，突然想到通讯的优先级是15，基本断定OB36被通讯打断的。接下来分析到底是什么通讯打断的定时中断。 

     PLC-ANALYZER pro 5 软件在线时，通过PLCWeb访问，发现Trace监控开始，CPU通讯增加了S7-Transport

     S7-Transport 属于S7通讯，通讯会造成扫描周期的加长。

         硬件配置中，模拟量模块输出的刷新 自动刷新和CPU的循环时间一致。                            

         CPU扫描周期过长，模拟量输出的刷新也同步加长（访问过程映像区）所以会造成控制不稳定。

         需要注意的是此时即使使用高优先级的定时中断，中断的时间也能够保证。也是没有作用的。因为定时中断时间短，可以多次写模拟量过程映像区，由于过程映像区刷新和低优先级的PLC的扫描周期关联，即使多次写过程映像区，过程映像区也不刷新到模块的模拟量输出，所以也起不到作用。

解决方案

       1：模拟量输出地址过程映像区的刷新放到PIP中，和使用的定时中断的时间一致。

这样既保证了数据的一致性，也保证了每次运算时，都可以将过程映像区的数据直接就可以作用到模块。 

      2：使用：P的访问方式，此种方式可以直接对模块进行作用。但是通过Trace曲线监控，和刷新地址放在中断OB中，数据一致性没有放在循环中断OB中的好。从访问速度上来说，两者是一致的。 

      3：由于OB的优先级13，低于通讯。                        

         所以通讯的优先级要高。通讯的增加必然造成了CPU循环时间的加长。                     

         将循环中断的OB的优先级高于通讯，设置成16。此时刷新就不会受到PLC Anlyzer的影响。

 4.经验总结

 4.1遗留的问题

     1：为什么同样是通讯，使用PLC-ANALYZER pro 5监控时，对系统影响比较大，包括扫描周期和定时中断的执行。但是使用Portal 内置的Trace功能明显就影响小了很多。同样是通讯，优先级应该是一样的。为什么会造成不同的效果呢？现场也做过其他通讯对中断的影响，WINCC好像几乎没什么影响。影响的效果从高到低排列

         PLC-ANALYZER pro 5-----Trace---------Wincc。

     2：同样的应用，为什么在400中，使用PLC-ANALYZER pro 5监控的时候，影响就很小呢（此处需要验证，但是从以前调试的经验来看，好像没有什么影响）

     3：300 400PLC的定时中断是否也有类似排队和丢弃的机制。

查了相关手册，没有相关的信息。

     4：目前还怀疑PLC型号选小了，造成运算速度慢应该也有一定的关系

         通过PLC的web查看，用户程序负载82%，这是值合不合理？是不是有点大？

         以前项目好像没有这么大，通过这两个参数能不能判断CPU选型是否合适？

         另外在300 400中这个信息是不是无法查看？

4.2改进方法

        通过选型软件的移植分析来看，此项目的PLC明显选小了                      

        后期项目使用至少CPU1517。通过手册来看，CPU1517运算速度和能力要比1516高很多，一般情况下，原先使用400PLC的项目，稳妥起见，还是CPU1517起步比较合适。

4.3 对S7-1500新功能或者更新替代的方式和方法的一些看法和建议

        S7-1500 优化的OB块支持排队的数量可以设置，感觉这个功能没什么必要。因为排队意味着会造成扫描周期会因为排队数量的增大而增大。现场做过测试，如果OB时间设置太小的话，造成大量的排队事件，触发了最大循环时间看门狗150ms的问题。如果工艺上确实需要很小的扫描周期的话，那就是PLC选小了。如果不选择上过载事件将在诊断缓冲区中留下一次记录，很难发现这个问题。