昨天到一個項目地調試的時候，突然發(fā)現(xiàn)s7-300plc報sf故障，于是聯(lián)機發(fā)現(xiàn)報ob121編程故障，如下圖：
個人感覺很奇怪，因為之前一直運行ok，難道是問題一直有，沒人發(fā)現(xiàn)？
手機上網(wǎng)查詢找答案的相關問題后，聯(lián)機plc在線刪除了ob121，觸發(fā)plc停機，然后找到了故障點，修改地址后重新下載，啟動plc后正常。
事故處理后細想，其實距離不讓plc停機就找到故障點只差最后一步了。因為本人通過事件的觸發(fā)時間，幾乎間隔100ms觸發(fā)一次，初步判斷應該在ob35，因為是背景db，也在調用fb塊的地方查看有沒有什么1576出現(xiàn)過，無奈眼拙沒找到。其實只要通過編輯里的查找替換，輸入1576，就可以迅速定位到錯誤地址。
分析報警信息，其實已經(jīng)說的很明白，只是以前沒經(jīng)歷過，不能理解。
讀取時發(fā)生區(qū)域長度錯誤：讀取操作，指令的左邊。
背景db，雙字訪問，訪問地址：1576：調用fb時背景數(shù)據(jù)賦值錯誤，錯誤地址是dbd1576。
為了驗證以下的想法，通過仿真做了一下試驗：
1、 能否通過交叉參考定位到錯誤點。
2、 能否在plc不停機的情況下讓plc正常。
3、 如果ob121發(fā)生在ob1里，plc的工作情況怎樣？
等等
結果如下：
1、仿真時發(fā)現(xiàn)，報警信息可以通過“打開塊”直接進入故障點，而plc的“打開塊”是灰色的。
2、仿真時的cpu顯示正常，實際plc顯示出錯。
3、交叉參考不能定位dbd1576。
4、通過交叉參考查找程序結構，看哪些塊調用fb，可在響應的程序塊中查找定位。
有點搞笑，驗證到最后，最簡單的不讓plc停機，直接查找到故障點，就是通過仿真，修改問題程序后直接下載到plc中。
需要說明，仿真的時候沒辦法下載程序。
好吧，我再一次驗證了仿真的重要性~