通信與診斷——黑盒跑通就算完，故障時兩眼一抹黑

錯誤現象
兩臺S7-1200之間用Put/Get通信，配置完連接后測試能傳數據，項目就封包發貨了。半年后客戶報修：設備隨機丟包，有時數據幾個小時不更新。現場工程師打開程序，沒有通信狀態監控，沒有故障代碼輸出，不知道是網絡閃斷還是CPU停機。

錯誤后果

• 故障定位耗時占整個維修時間的80%。

• 非專業人員反復斷電重啟，損壞設備。

• 客戶對品牌技術能力產生質疑。

根本原因

• 通信編程只關注數據收發，不關注通信質量。

• 不知道系統數據類型（如TCON、TSEND、TRCV）的狀態字含義。

• 缺乏工業網絡基礎知識，混淆TCP、PROFINET、ISO-on-TCP。

避免方法

1. 強制加入通信狀態監控
   使用TCON、TSEND、TRCV指令時，必須將狀態輸出字（STATUS/ERROR）存入DB，并在HMI上顯示。一旦通信失敗，立即輸出“通信故障_線體A”而非“數據為0”。

2. 利用系統診斷緩沖區
   編程習慣：發生嚴重故障時，觸發RDREC讀取CPU診斷緩沖區，將近十條故障存入歸檔DB。維護人員可通過HMI查看PLC歷史停機原因。

3. 定期心跳檢測
   主從站約定一個DWord作為心跳計數器，從站每周期加1，主站監控。若心跳停止超時，主動報警并進入安全狀態。

4. 標準化通信模板
   不要每次重寫通信程序。建立封裝好的FB_Client、FB_Server，參數化IP地址、數據長度、超時時間。確保每次調用都包含錯誤處理邏輯。

小結
通信程序寫完只完成了一半，另一半是讓故障“可見”。