到底是谁动了我的PLC输出

时间：2023-03-17来源：佚名

I/O - 输入输出，大家都非常熟悉，自动化系统中无处不在。我们通过操纵一系列的I/O来达到预期的控制目标。然而调试中却经常会出现一些不按预设逻辑工作的输出，如图1中所显示的，Q0.0~Q0.3已经接通了，但实际模板却没有输出，在变量表中监视这些地址，发现这些地址确实为断开状态。到底是谁动了我的输出呢？

通常大家首先会考虑，可能程序的其他地方也使用了这些输出从而导致不正常，我们可以使用go to Location功能来查找整个项目中哪些地方都使用了Q0.0，如图2。

在图3的Go to Location中选中“Overlapping access to memory access”可以查找项目中包含地址Q0.0的所有变量，但是发现除了在OB1的Network1有对Q0.0进行写操作的指令，即目前监视的位置外，再没有其他的地方使用这个地址。查到这可能很多人就不淡定了，认为自己的程序完全没有问题，接着开始抱怨模板问题，CPU问题。。。

其实对程序的排查并没有完成，Go to Location功能只能搜索离线的程序，无法搜索实际在plc中运行的程序。一台PLC可能被下载过很多套程序，而我们拿来后，未经任何处理，就直接下载自己的项目到PLC，可能会遇到PLC在执行一些离线项目中并不存在的OB块的情况。例如曾经下载到PLC的程序中包含OB35，但目前的离线项目中却并没有使用OB35，PLC依然会周期执行OB35里的指令，如果OB35里包含对Q0.0的复位指令，也会出现图1所示的故障。STEP 7提供了一个简单的方法来排除这种情况：使用SIMATIC Manager 窗口下PLC菜单中的“Download User Program to Memory Card”功能重新下载项目程序，此功能会先删除PLC中所有的内容，然后再下载离线项目到PLC中，这样就能避免“隐藏”在PLC中程序的干扰。
另外还有一种情况是程序中使用了间接寻址，Go to Location功能只能搜索到已使用的静态地址，而无法确定需要在运行中动态计算出的地址。
例如：
CLR
= Q [MD100 ]
MD100不同的值将导致不同的Q点被复位
MD100 = 16#0 ，Q0.0 = 0
MD100 = 16#1 ，Q0.1 = 0
对于自己编写的程序，大家都确切的知道在哪使用了间接寻址，可以单独把这些程序段拿出来进行单步调试，以避免对地址的误操作，而调试由其他人编写的或厂家提供的功能块，甚至这些块被加密保护了，则只能使用排除法，先将这些块都删掉，然后再一点点添加到程序中，来判断是哪些程序段造成的错误输出。例如FM350-1 lib提供的功能块FC2，如果硬件组态时忘记将FM350-1的模板地址设置到指定的DB中，由于DB初始值默认都是0，就会影响QB0~QB15的输出。
最后为了快速定位到底是不是程序问题，一个简单的方法就是在线删掉PLC中所有OB块，然后在硬件组态窗口中启用模板的监视/修改（Monitor/Modify）功能，通过此对话框直接修改输出，如图4所示，输出显示都正常，说明问题还是出在程序上。