本期內容來自群內網友投稿，一個真實的S7通訊故障處理及解決過程，Zui終問題也比較少見，因此群友希望將處理過程發出，讓大家遇到類似問題時候可以少走些彎路。

01 問題描述

現場兩臺西門子 S7-1200 PLC通過S7單邊通訊實現CPU與CPU之間的數據交換，產線開機前已對通訊進行測試，一切正常，并在程序中加入了斷線報警功能（通過心跳檢測報通訊是否正常，數據超過10秒沒有被復位則判斷通訊中斷），隨后導入生產；連續穩定運行1個月后，突然收到生產人員反饋，兩條線HMI經常報警通訊故障，而且頻率很高，嚴重影響生產；然后就開始了問題檢查處理；

心跳報警程序HMI報警截圖

02 系統架構說明

系統架構

產線AIP 地址1214CPU + 9個  Smart 200 PN站 + 3 個 威綸通 CMT系列HMI；

PLC_A IP	192.168.3.10	S7客戶端，發起S7通訊
HMI1_IP	192.168.3.14	實際也是S7客戶端，占用S7鏈接資源，主動鏈接
HMI2_IP	192.168.315	實際也是S7客戶端，占用S7鏈接資源，主動鏈接
HMI3_IP	192.168.3.16	實際也是S7客戶端，占用S7鏈接資源，主動鏈接
PN站 IP		PN通訊無故障，此處不在贅述

A線硬件組態

產線B線IP 地址1214CPU + 9個  Smart 200 PN站 + 3 個 威綸通 CMT系列HMI；

PLC_A IP	192.168.3.20	S7服務端，被動鏈接
HMI1_IP	192.168.3.24	實際也是S7客戶端，占用S7鏈接資源，主動鏈接
HMI2_IP	192.168.3.25	實際也是S7客戶端，占用S7鏈接資源，主動鏈接
HMI3_IP	192.168.3.26	實際也是S7客戶端，占用S7鏈接資源，主動鏈接
PN站 IP		PN通訊無故障，此處不在贅述

B線硬件組態

03 問題分析 & 排除

在收到現場反饋后，立馬著手開始問題分析，抓緊解決問題。因為是偶發情況，第一時間鏈接電腦并沒有發現問題；

判斷1：

根據情況描述，第一感覺是有IP沖突，畢竟已經連續運行1個月沒有問題；突然間斷性出現通訊故障，IP沖突可能較大；

檢查方法：

1. 使用“Ping”命令，對PLC_A 和 PLC_B分別進行 IP 測試；發現ping命令均正常，且經過長時間測試，一直沒有中斷過，測試速率也很快；

   Ping IP 測試

2. 使用 IP 掃描工具 IPScaner 及 Ethernet Device Configuration分別對系統內所有IP設備進行掃描，結果也都正常，并沒有出現重復或者無法掃描到的；

   IP 掃描工具掃描

結論：上述兩種方法都確定沒有問題，IP沖突引起異常排除；

判斷2：

排除IP沖突后，感到問題可能有點麻煩了，然后開始懷疑PLC_A(客戶端)中的S7通訊程序PUT、GET指令，參數設置是否有問題，隨進行參數及程序檢查；（實際內心覺得這里出問題的概率很小,要不然不會穩定運行那么久）

檢查內容：

1. PLC_A中組態鏈接中伙伴地址，TASP是否正確(非同一項目中的兩套程序)

   A線鏈接組態A線鏈接TASP

2. 檢查PUT、GET觸發條件，發送及接收地址，背景DB是否重用

   Get命令PUT 命令

3. 檢查CPU屬性設置中，是否勾選允許來自遠程的PUT，GET ，這一項基本上可以肯定已經勾選了，否則一開始就通訊不上；

   A線鏈接機制B線鏈接機制

結論：以上3點檢查完成，果然如之前所料，并沒有異常；

判斷3： 事情到了這一步，確實是有點棘手了。由于產線已經是生產狀態，所以無法進行停機更換網線或者交換機了，并且通過上面測試，網絡應該是正常的，跟網線及交換機應該問題不大。判斷程序應該執行過程中還是有錯誤了；

檢查方法：

沒有辦法只能盯著程序看通訊狀態了(好在通訊異常的情況挺頻繁)，這一來還真發現問題了！每次通訊故障，PUT/GET命令狀態同時進入16#19(已開始通信，作業正在處理。)保持不變，也沒有錯誤狀態，然后持續60多秒后自動復位（心跳程序中有計時），很明顯通訊程序出現了問題，但是不知道如何解決了。隨后，打西門子熱線尋求幫助，給出的檢查結果如下：

1. 指令和指令觸發沒有問題，配置沒有問題；
2. 持續60多秒的通訊肯定有問題，而且狀態16#19不是真實的狀態，可能在這個過程中發生了錯誤，但是錯誤代碼一閃而過(可能是一個掃描周期)在TIA portal中監控不到(有1.5語了)
3. 建議在程序中增加一段錯誤追蹤程序，即檢測到錯誤代碼后，把當前狀態MOVE到另外一個寄存器，就可以看到狀態代碼了；

按照西門子客服的建議，增加了錯誤捕獲程序，繼續跟進問題

錯誤捕獲程序

結論：本以為這次終于能夠發現問題了，結果等了一上午，報警倒是不少，但是錯誤一個沒抓到，真正的問題還是沒有找到，只能繼續跟進；

判斷4： 現在開始，著實有點崩潰了；這么長時間依然沒有找到問題，剩下的只能是瞎貓碰死耗子了，東搞搞，西看看了；突然靈光一現，這么長時間了，一直在找客戶端的問題，會不會服務端有問題？（因為正常S7通訊服務端不需要做任何程序，所以沒往哪方面想，也只能檢查下在線鏈接狀態）

檢查方法：

首先查看客戶端的鏈接狀態和數量--1個S7鏈接 + 3 個 HMI + 1個PC在線，剛好5個，跟設計一致，運行正常；

A線鏈接狀態和機制

接著檢查服務端鏈接狀態和數量，這一看就不得了了，竟然出現了20多個鏈接，通信鏈接資源也全部被占用。。如下圖：

B線鏈接狀態和機制B線鏈接資源使用情況

結論：通過上面的分析，基本可以斷定問題根源--由于B線產生了過多的鏈接，造成通訊鏈接全部被占用，A線發起的S7鏈接出現網絡阻塞，導致通訊時間過長，甚至無法通道；終于長出了一口氣，搞自控的不怕有問題，就怕問題不知道哪里來的；

04 問題解決

經過的上面的排查，Zui終問題定位到了B線PLC通訊鏈接上面，問題無非是CPU問題或觸摸屏問題。通過將觸摸屏網線斷開，發現問題依然存在，判斷應該是CPU有問題。

于是，將相關信息提交給西門子技術支持，西門子技術支持認可了判斷結果，給出的建議是先對CPU進行恢復出廠或者升級固件版本，如果都不行則需要更換該CPU返廠檢查；

Zui終，通過同廠內溝通，停下生產，進行了一次CPU固件升級，問題解決；

問題解決后通訊鏈接