昨天到一个项目地调试的时候，突然发现s7-300plc报sf故障，于是联机发现报ob121编程故障，如下图：
个人感觉很奇怪，因为之前一直运行ok，难道是问题一直有，没人发现？
手机上网查询找答案的相关问题后，联机plc在线删除了ob121，触发plc停机，然后找到了故障点，修改地址后重新下载，启动plc后正常。
事故处理后细想，其实距离不让plc停机就找到故障点只差最后一步了。因为本人通过事件的触发时间，几乎间隔100ms触发一次，初步判断应该在ob35，因为是背景db，也在调用fb块的地方查看有没有什么1576出现过，无奈眼拙没找到。其实只要通过编辑里的查找替换，输入1576，就可以迅速定位到错误地址。
分析报警信息，其实已经说的很明白，只是以前没经历过，不能理解。
读取时发生区域长度错误：读取操作，指令的左边。
背景db，双字访问，访问地址：1576：调用fb时背景数据赋值错误，错误地址是dbd1576。
为了验证以下的想法，通过仿真做了一下试验：
1、 能否通过交叉参考定位到错误点。
2、 能否在plc不停机的情况下让plc正常。
3、 如果ob121发生在ob1里，plc的工作情况怎样？
等等
结果如下：
1、仿真时发现，报警信息可以通过“打开块”直接进入故障点，而plc的“打开块”是灰色的。
2、仿真时的cpu显示正常，实际plc显示出错。
3、交叉参考不能定位dbd1576。
4、通过交叉参考查找程序结构，看哪些块调用fb，可在响应的程序块中查找定位。
有点搞笑，验证到最后，最简单的不让plc停机，直接查找到故障点，就是通过仿真，修改问题程序后直接下载到plc中。
需要说明，仿真的时候没办法下载程序。
好吧，我再一次验证了仿真的重要性~