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所示，输出显示都正常，说明问题还是出在程序上。