案例2：

   现场用户反映，更换CPU后，S7-300 通过集成的DP接口连接的驱动工作不正常了，控制的转速突然增加，造成部分生产的产品不合格。用户使用USS方式测试也没有问题，所以最终怀疑是DP与驱动设备通信中断造成转速发生跳变。

   现场工程师到现场后按照用户的问题描述就测试DP通信了，结果什么也没有测试出来，在CPU的诊断缓存区中也没有掉站故障信息，然后就怀疑是不是这个批次PROFIBUS芯片有问题，这下就麻烦了，被带进沟里了，而且很深，爬不出来了，没有办法找到我这里进行咨询。我听了一遍问题的描述，首先排除产品问题，如果产品的问题，可以使用一个分布式I/O测试一段时间，如果没有问题，就可以说明产品没有问题。再说了，产品有问题也是可以正常工作一段时间或者通信完全不能建立，而且没有报DP从站故障，怎么也不能怀疑产品问题吧。不是产品问题那只能是程序问题了，我让现场工程师问一下用户，驱动是使用PID进行动态调速还是直接由主站发送一个设定的转速？结果是使用STEP7 中集成的PID FB41进行调速的。我让现场工程师再看看程序，是不是FB41在OB1中调用的，结果也是按照我猜想的那样，这样问题的原因就找到了。下面是问题的分析：大家还记得FB41有一个参数 “CYCLE” 吧，这个参数是两次调用FB41的间隔，如图1所示。

图1 FB41参数

   如果是1s，就需要在设定循环中断为1s的OB块中调用，所以说参数“CYCLE”与OB35设置的循环中断时间有关。“CYCLE” 设定完成后才能决定积分时间和微分时间，例如TI要求 >=5* CYCLE，如果在OB1中调用，参数 “CYCLE” 、 “TI” 和 “TD” 的值可能都是调试的结果而不是在正确条件下整定的值。TIA博途中新增加PID指令 “PID_Compact” （只适用于S7-1200/1500），早期版本中带有循环时间这个参数，如果设定的值与循环中断OB的设置时间不匹配，在自整定时会报错。新版本中，自整定会自动计算出循环时间，根据这个值再修改循环中断OB的设定值。新CPU更换后，扫描周期快了好几倍，原来的PID参数当然就就不适合了。还是这个原则，CPU快了反而出错了一定是程序编写的不严谨。从另外一点也可以看到，后续推出的软件也越来越智能，如果当时用户使用了S7-1500，整定时报错，可能就会避免上面的问题。

  案例3：

   现场是一个零件加工设备，控制器使用一个S7-300的CPU。设备加工是按顺序执行的，程序使用Graph编写，Graph也特别适合顺控，走完一步后再执行下一步，每一步都有确定的操作任务，执行完所有步骤后返回再加工新的设备。现场问题描述是这样的：完整加工一个零件后再更换新的CPU，启动设备后，加工过程就停止了，换回旧CPU后操作正常。问题的描述是现场工程师告诉我的，我听了也不相信，这种事怎么可能呢？更换新CPU不就是想提高CPU的扫描速度，从而加快加工的节拍吗，按照常用的方法加延时，怎么也会正常启动吧，结果这回不好使了，没有办法只能自己去现场了。

   到了现场后，等零件全部加工完后，更换CPU，下载程序并启动设备运行，设备好像尝试动了动又停止了，CPU没有报任何故障信息，换回旧CPU后设备可以正常运行。难道程序有BUG？再次更换新CPU并加延时程序，设备还是不能运行，说明现场工程师的描述是正确的。加延时程序也不行，说明不是程序的BUG，而是程序中的状态保持了，没有满足当前的条件所以不能运行。记得有一次到啤酒厂测试DP通信，控制也是一步一步按顺序运行，在没有全部运行结束前是不能停机测试的。借这段时间做了些准备工作，例如检查网络拓扑、DP接头是否带有编程接口等，结果卸下DP通信接口盖板时不巧碰到了CPU的启停开关，CPU切换到STOP模式，我赶紧再切换到RUN模式，表面一切正常，但是过程不往下执行了，就是条件不满足导致顺序被卡住了。现场看程序解决问题是不切合实际的，最后只能找熟悉程序的工程师手动一步一步往下走，完成一个循环后再切换到自动运行。有了这个经验后，判断CPU中原先DB块中肯定存储着状态值，下载硬件后导致状态变化而不能正确运行。先初始化GRAPH的实例化数据块，还是不能运行。既然这样了也别一个DB块一个DB块的初始化了，使用CPU上的开关直接全部初始化DB块，然后再次运行设备。设备也是经过了一段加工前的准备工作后才开始正常的加工工作。有点明白了，全新的设备开始运行时会进行准备工作，准备工作完成后记录一些信息到DB块中，第二次操作就不需要再次做准备工作了，更换CPU可能导致部分数据丢失（测试时使用新的MMC卡）。所以更换任何CPU都会导致加工过程中断的，还有就是程序是上载的，DB块中带有过程值，如果使用最初始的程序，可能也就没有问题了。

崔工的技术类文章请移步至1847大咖专栏