直接開始寫。這篇系列文章到了第三篇前面肯定已經講了TCP通訊怎麼配置、怎麼編程這篇的重點就是“測試”——在一個完整項目交付之前通訊能不能通、數據準不準、掉線重連是否可靠這些如果不做紮實的測試到了現場再折騰代價就大了。尤其西門子PLC做TCP通訊很多時候是跨項目調用程序塊、背景數據塊、連接參數都得自己管稍微不留神就是各種奇葩問題。我把實測過的一整套測試方法、工具選型、踩坑記錄整理出來希望能幫你少走彎路。1. 為什麼TCP測試是PLC通訊項目中最容易被低估的環節做西門子PLC的TCP通訊很多人覺得“配置一下IP、調用幾個塊、能連上就完了”。實際上真正讓工程師頭疼的往往不是通訊建立不起來而是通訊不穩定、數據時對時錯、斷線之後重連不上。這些問題在實驗室裡不明顯一到現場就爆發而且排查起來極其耗時。我在做過多個跨項目TCP通訊之後最大的體會是TCP測試不是“最後驗證一下”而是要貫穿配置、編程、聯調的全過程。測試做得好能把90%的隱患消滅在出廠之前測試做得糙到了現場就是“盲人摸象”。1.1 “不同項目下”這個前提到底意味著什麼標題特意強調“不同項目下”這裡面有幾個關鍵含義獨立的項目文件幾個PLC各自有獨立的項目工程不是在同一個TIA Portal項目裡組態。這就意味著沒有全局的“連接表”能自動管理每個PLC都要自己維護通訊參數。連接資源獨立每個項目有自己的連接資源分配跨項目通訊時雙方必須手動約定好通訊協議、端口號、數據長度、觸發方式。診斷信息不共享調試時出了問題你只能在本端看診斷緩衝區、連接狀態對方PLC的狀態需要通過其他方式協同確認比如現場對講機、手機截圖或者乾脆兩台電腦並排擺著調。正因為這種“物理上獨立、邏輯上互聯”的結構測試方案就不能只測“能不能連上”而是要測“連上之後的數據交互是否正確”“異常情況下能否自動恢復”。我把這種測試思路總結為“三層測試”連接層測試、數據層測試、異常恢復測試。1.2 測試前必須明確的網絡拓撲在動手測試之前先把網絡結構畫清楚。最常見的拓撲有兩種第一種PLC直連PC或PLC直連PLC用一根網線直連這種方式最簡單排除了交換機、路由器、防火牆等中間設備干擾。適合做最基礎的通訊驗證。第二種PLC通過交換機接入工業環網或星型網絡這種方式更接近現場實際。多台PLC、上位機、HMI都掛在同一個交換機下面。測試時要注意IP地址規劃、VLAN劃分、廣播風暴等問題。我個人的習慣是先在直連模式下把通訊調通再切換到交換機環境做二次驗證。直接上交換機一旦不通你根本分不清是PLC配置錯了還是交換機阻断了。2. 測試前的準備工作硬件、軟件和通訊參數規劃這部分看起來基礎但恰恰是現場出問題最多的源頭。很多工程師拿了一個測試工具就開始發數據結果發現通訊一直建立不起來最後才發現是IP地址不在同一網段或者PLC的連接機制沒搞對。2.1 準備清單從硬件到軟件我梳理了一份測試前必須準備好的清單你可以直接照著核對類別項目說明硬件PLC本體/CPU至少兩台支持TCP通訊的西門子PLC例如S7-1200、S7-1500硬件以太網網口/通訊處理器集成PN口即可部分老型號需要CP卡硬件網線直連用交叉線部分設備支持自動翻轉但保險起見備一根交叉線硬件交換機組網測試時必備工業級或普通千兆交換機均可軟件TIA Portal至少V15及以上不同版本之間項目兼容性要注意軟件網絡調試助手TCP調試工具例如NetAssist、TCPUDP測試工具等軟件Wireshark抓包分析利器排查隱性問題必備文檔IP地址規劃表明確每台設備的IP、子網掩碼、網關文檔通訊數據表明確功能碼、寄存器地址、數據類型、長度、週期2.2 IP地址規劃與端口號選擇的學問IP地址跨項目通訊最忌諱IP亂配。我見過有現場把PLC的IP設成192.168.1.1另一台設成192.168.0.1中間還有一個路由器沒配置靜態路由結果兩台設備根本不在一個網段ping都ping不通。測試前先把以下信息寫成表PLC A的IP例如192.168.0.10端口號2000PLC B的IP例如192.168.0.20端口號2000PC調試機的IP例如192.168.0.100端口號西門子PLC的TCP通訊端口號必須雙方約定一致。常見選擇有2000西門子常用於自定義TCP通訊102S7協議默認端口如果你用的是TSEND_C/TRCV_C類塊這不是必須的任意大於1024的端口自行定義時盡量避開知名端口注意如果PLC作為服務器被動監聽你需要在PLC裡設置監聽端口如果PLC作為客戶端主動連接你需要在PLC裡指定對方的IP和端口。這個“誰主動誰被動”的角色定位一定要在測試前雙方溝通清楚否則就會出現“兩邊都在等對方連自己”的尷尬局面。3. TIA Portal中TCP通訊的核心配置與程序框架這一部分我們以西門子S7-1200/S7-1500常用的TSEND_C / TRCV_C通訊指令為例展開因為它是西門子TCP通訊裡最典型、最常用的一組指令。如果你用的是老式S7-300/400的AG_SEND/AG_RECV思路類似只是塊的參數和配置方式略有不同。3.1 創建連接兩個項目各自搞定“連接描述”在客戶端主動連接方打開設備組態進入“網絡視圖”或者“連接”頁面。新建一個連接選擇“TCP連接”。指定連接夥伴這裡是關鍵因為是跨項目夥伴無法從當前項目樹中直接選擇“未指定”或者手動填寫IP地址。在連接屬性中設置本端端口、夥伴的IP地址和端口。給這個連接起一個容易識別的名字比如“TCP_TO_B”後續程序塊直接引用。在服務器端被動監聽方同樣新建一個TCP連接。夥伴選擇“未指定”等待客戶端來連接。設置本端監聽端口比如2000。注意被動端的連接描述不需要填對方的IP有些版本填了也行但通常建議留空讓系統自動接受任意客戶端連接。3.2 程序框架搭建TSEND_C與TRCV_C的使用要點TSEND_C和TRCV_C這組塊的特點是連接管理、數據發送/接收都在同一個塊裡完成。你只需要在背景數據塊裡維護連接參數然後在OB1或者循環中週期調用即可。// 客戶端PLC A發送示例 TSEND_C_DB( REQ : Send_Trigger, // 沿脈衝觸發發送 CONNECT : TCP_Conn_A, // 連接描述指向組態好的TCP連接 DATA : Send_Data, // 要發送的數據區 DONE Send_Done, BUSY Send_Busy, ERROR Send_Error, STATUS Send_Status );// 服務器端PLC B接收示例 TRCV_C_DB( EN_R : true, // 始終使能接收 CONNECT : TCP_Conn_B, // 連接描述指向組態好的TCP連接 DATA : Recv_Data, // 接收數據存放區 NDR Recv_NDR, // 新數據到達標誌 LEN Recv_Len, // 實際接收的字節數 ERROR Recv_Error, STATUS Recv_Status );這裡有一個非常重要的經驗REQ觸發信號最好用沿脈衝不要用電平。如果REQ一直為TrueTSEND_C會反覆發送同一幀數據對方會收到大量重複數據數據刷新頻率完全不可控。我見過有人用時鐘脈衝塊如Clock_1Hz直接驅動REQ結果通訊量暴增CPU掃描週期都受到了影響。正確做法是在數據更新完成後置位一個發送標誌發送完成DONE後復位這個標誌確保“有新數據才發送”。TRCV_C的接收端EN_R一直為True沒問題這是正常的。但有個細節要注意LEN參數。如果你用固定長度接收LEN輸出的就是固定長度值如果你用可變長度接收比如TCP協議下的數據長度不確定LEN會返回實際接收到的字節數。建議在數據幀的設計裡加上幀頭、幀尾或者長度字段便於接收端判斷一幀數據是否完整。3.3 數據區定義與字節序的坑跨項目TCP通訊數據區的長度和數據類型必須提前定義好誰發送多少字節、誰接收多少字節必須一拍即合。常見錯誤是A發送的數據區長度是10個字節B的接收數據區定義成了20個字節。這樣B收到的數據只有前10個字節是有效的後面10個字節是殘留的舊數據如果程序邏輯沒有處理好很容易造成誤動作。還有一個很容易踩坑的是**字節序Byte Order**問題。西門子PLC默認是大端模式Big-Endian但很多第三方設備比如某些上位機、儀表、視覺系統默認是小端模式Little-Endian。如果你不確認這個傳過去的數值很可能“翻轉”了。例如16位整數0x1234大端傳輸是12 34小端設備收到後解析成0x3412數值完全不對。解決辦法測試時先發送一組已知的測試數據比如0x01、0x02、0x03、0x04然後觀察對方接收到的字節順序。如果順序反了寫個字節交換的小程序或者在塊參數裡調整數據類型。4. 測試方法詳解從ping通到數據驗證接下來進入這篇文章的重頭戲——具體怎麼測。我建議按照“從底層到上層”的順序一層一層往上測。每一層通過了再進入下一層這樣出了問題能快速定位。4.1 第一層測試物理鏈路與IP連通性操作用網線連接PLC和PC或兩台PLC通過交換機連接。在PC上打開CMD執行ping 192.168.0.10 -t如果ping不通先查網線、網口、IP地址、防火牆。經驗有些時候ping不通不代表TCP完全不可用可能只是PLC不響應ICMP請求。S7-1200/1500默認情況下是允許ping的但你可以在設備屬性裡禁用“允許來自遠程對象的訪問”之類的選項這會影響ping的回應。如果ping不通先別急著斷定網線有問題到TIA Portal的在線診斷裡看一下設備是否在線。進階想確認端口是否監聽可以用PC上的網絡調試助手開啟TCP Server監聽某個端口。如果PLC作為客戶端能連上說明PLC的TCP客戶端功能正常如果連不上再看PLC的診斷緩衝區有無報錯。4.2 第二層測試利用TCP調試工具做“假伙伴”測試很多時候測試初期只有一臺PLC沒有另一臺可以配合。這時PC上的TCP調試工具就是最好的“假伙伴”。場景一PLC作為服務器在PLC裡組態一個TCP連接被動監聽端口2000。在PC上打開TCP調試工具選擇“客戶端”填入PLC的IP地址和端口2000。點擊連接觀察PLC側的連接狀態是否變為“已建立”。PC發送一串測試數據比如“01 02 03 04 05”觀察PLC的接收數據區是否更新為同樣的數據。場景二PLC作為客戶端在PC上打開TCP調試工具選擇“服務器”監聽某個端口比如3000。在PLC程序裡觸發TSEND_C通信讓PLC主動連接PC。連接成功後PLC發送數據PC端觀察收到的數據是否正確。這個階段的測試重點是確認連接方向、端口號、數據長度基本正確。如果這個測試都過不了那就別急著去聯兩臺PLC了先把基本配置搞定。4.3 第三層測試雙PLC直連測試有了PC假伙伴測試的基礎再進入雙PLC直連測試就順暢多了。步驟按之前規劃的IP地址設置好兩臺PLC。PLC A作為客戶端TSEND_CPLC B作為服務器TRCV_C。在PLC A裡寫一個簡單的循環發送程序計數器每加1就把當前值發送給PLC B。在PLC B裡寫一個接收程序把接收到的數據存到某個DB塊裡。用TIA Portal分別在線監控兩臺PLC的變量觀察計數值是否連續遞增且無漏計。判斷標準通訊持續5分鐘無斷線。發送計數值和接收計數值一致無丟包。數據內容逐字節一致。如果出現數據對不上先用調試工具確認是“鏈路問題”還是“數據格式問題”。鏈路問題通常是連接不穩定、偶爾掉線數據格式問題則表現在數值大小不對、高低字節顛倒等。4.4 第四層測試抓包分析Wireshark如果雙PLC直連測出了奇怪的問題比如通訊時斷時續、偶爾超時建議直接上Wireshark抓包。抓包看什麼三次握手客戶端發SYN服務器回SYNACK客戶端再回ACK。三次握手不完整說明連接建立失敗。數據包序號TCP是可靠傳輸序列號和確認號應該是連續的。如果出現大量重傳說明鏈路質量差或緩衝區溢出。斷開連接正常斷開是四次揮手異常斷開可能是RST包。看到RST包說明某端異常關閉了連接。如何抓包把PC的網卡設置為與PLC同一網段用交換機的鏡像端口或者直接用PC作為中間節點串在PLC和服務器之間需要開啟IP轉發然後在PC上運行Wireshark抓包。抓包的數據怎麼解讀我舉個例子假設PLC A發送了一幀數據內容是“01 02 03 04”你在Wireshark裡過濾tcp.port 2000能看到這四個字節是否原樣出現在TCP負載裡。如果看到負載反了比如“04 03 02 01”那基本可以鎖定是字節序問題。5. 常見問題與排查技巧實錄這一部分我把自己在實戰中踩過的坑和同行交流中高頻出現的問題做一個匯總方便你遇到問題時對號入座。5.1 連接建立失敗狀態停留在“正在建立”現象PLC的TSEND_C/TRCV_C狀態字顯示連接正在建立但始終不成功。排查思路可能原因檢查方法解決措施IP不在同一網段ping測試統一IP規劃端口號不一致雙方連接屬性對比修改端口一致防火牆阻攔PC防火牆臨時關閉測試添加允許規則連接資源衝突檢查PLC診斷緩衝區報錯刪除多餘連接夥伴地址填寫錯誤核對IP和端口修正連接參數重點講一下“連接資源衝突”。S7-1200的連接資源有限如果你在同一個PLC裡建了多個TCP連接但是程序裡沒有全部調用有些連接會佔著資源不放。我遇到過一個情況組態裡建了5個連接程序裡只使用了2個結果另外3個連接一直處於“佔用”狀態導致新的連接建立失敗。解決辦法是刪掉不用的連接或者統一使用“編程和診斷”連接。5.2 偶發斷線後無法自動重連現象通訊運行一段時間後突然斷開PLC側顯示連接斷開但對方設備並未重啟。原因分析TCP保活機制西門子PLC默認的TCP Keep-Alive時間可能比較長如果中間有交換機或防火牆空閒連接會被中斷。發送/接收緩衝區溢出如果對方發送的數據過快而PLC的接收緩衝區不夠大可能導致緩衝區溢出連接被重置。應用層看門狗有些上位機會週期性檢查通訊狀態超過一定時間沒有收到數據就主動斷開連接。解決辦法在TSEND_C/TRCV_C塊的啟動參數裡設置合適的CONNECT超時時間。對於PLC作為客戶端的情況可以在斷開後通過程序控制重新觸發連接。具體做法是監測連接狀態字的ERROR或STATUS位當檢測到斷開時暫停一段時間然後再置位REQ重新發送數據觸發重連。如果是被動監聽端可以考慮在PLC裡啟用“接受任意連接”模式避免因連接參數中的夥伴IP變化導致無法重連。5.3 數據偶爾錯位或殘留舊數據現象接收端收到的數據有時是空的有時是上一次的舊數據有時前幾個字節是錯的。原因LEN參數沒用好如果對方發送的數據長度可變而你用固定長度接收就可能出現數據錯位。沒有幀同步機制TCP是流式協議沒有報文邊界。如果發送端發了兩幀數據接收端可能一 次收到兩幀也可能一幀分成兩次收到。解決辦法在應用層加上幀格式定義建議採用“幀頭長度數據校驗”的結構幀頭2字節 | 長度2字節 | 數據N字節 | 校驗1字節可選 AA 55 | 00 05 | 01 02 03 04 05 | ...接收端程序先搜索幀頭再根據長度字段讀取完整一幀然後做校驗。這樣即使TCP拆包粘包也能保證數據解析正確。這個方法在工業現場非常實用建議在設計階段就加入。5.4 通訊速度慢吞吐量上不去現象通了數據也對但刷新週期遠低於預期。原因TSEND_C/TRCV_C是單連接串行發送如果REQ觸發頻率太低數據吞吐自然上不去。另外如果每次發送的數據量很小比如4字節而週期是100ms那通訊速率就是40字節/秒看起來自然慢。優化思路提高REQ觸發頻率但注意不要影響PLC掃描週期。把多個數據打包成一幀一次性發送減少握手次數。如果資料量極大考慮使用FETCH/WRITE模式或被動連接配合更高效的協議。5.5 8180錯誤代碼的真相熱搜詞裡提到了“西門子PLC通訊模塊8180錯誤代碼”這個我專門講一下。8180錯誤在S7通訊中非常常見它代表通訊伙伴無響應或連接中斷。常見場景對方網絡斷開對方IP地址不可達對方端點正忙無法及時回覆通訊超時時間設置太短排查方法先用ping確認物理鏈路。檢查對方PLC是否在RUN狀態程序是否在執行通訊功能。如果對方是第三方設備確認設備的通訊參數比如單次請求的數據長度是否與西門子PLC匹配。適當增加通訊超時時間有的設備響應慢默認超時時間不夠用。6. 測試工具推薦與選型心得工欲善其事必先利其器。TCP測試工具我試過不少下面這些是實際用下來靠譜的按場景分類推薦。6.1 網絡調試助手TCPUDP測試工具這類工具在國內工控圈最普及網上隨便搜就有很多版本基本功能都差不多支持TCP Server/TCP Client支持UDP單播/組播支持HEX格式收發支持週期發送建議在PC上同時開兩個實例一個做Server一個做Client這樣可以模擬兩個節點進行自測特別適合在沒有PLC環境的情況下先驗證自己的數據幀格式。6.2 Wireshark開源免費功能強大。抓包分析TCP三次握手、數據重傳、RST包、字節序問題全靠它。使用技巧過濾器用tcp.port 2000就能精確過濾指定端口。用tcp.flags.reset 1快速找RST包。用tcp.analysis.retransmission快速找重傳包。抓包時建議關閉其他網絡應用避免干擾。6.3 TIA Portal在線診斷這個不算“測試工具”但是排查通訊問題時必開。在線連接PLC後打開“診斷緩衝區”看有沒有通訊相關的錯誤事件。在“連接”視圖查看連接狀態是否“已建立”。在線監控TSEND_C/TRCV_C的狀態字能看到錯誤代碼。6.4 西門子SIMATIC NET相關工具如有條件如果項目涉及S7通訊或者需要和WinCC聯調SIMATIC NET工具包裡的“Station Configuration Editor”可以用來檢查通訊卡和連接情況。但是對於純TCP自定義通訊不一定需要用到這個工具記住前面的基礎手段足夠應對絕大多數場景。7. 完整測試流程模板從實驗室到現場前面拆解了單點測試方法這裡我給出一套可以直接套用的完整測試流程模板適用於“兩臺西門子PLC跨項目TCP通訊”的項目驗收測試。你可以根據具體項目調整裡面的參數。7.1 實驗室階段測試目的在可控環境下驗證配置、程序和數據格式。序號測試項測試方法預期結果1IP連通性PC分別ping兩臺PLC均通2PLC作為ServerPC客戶端連接PLC監聽端口連接成功收發數據正確3PLC作為ClientPC服務器監聽PLC觸發連接連接成功收發數據正確4雙PLC雙向通訊啟動雙方程序連續運行30分鐘無斷線數據一致5異常斷開恢復拔掉網線10秒後插回PLC自動重連數據恢復6數據幀格式驗證發送已知測試數據對比接收端字節順序和值完全一致7.2 現場階段測試目的在真實網絡環境下驗證穩定性、抗干擾能力和聯鎖邏輯。序號測試項測試方法預期結果1帶載測試啟動所有通訊任務觀察CPU負載CPU掃描週期在允許範圍內2網絡切換測試斷開主交換機端口切換備用網絡通訊恢復時間在允許範圍內3數據刷新率測試監控數據刷新週期滿足工藝要求4重啟測試重啟一臺PLC觀察自動恢復雙方恢復通訊無需人工干預5長時間穩定性測試連續運行24小時以上無斷線、無數據錯亂7.3 測試記錄規範測試不是“跑通了就行”要把過程記錄下來。我習慣用表格記錄每一次測試的測試時間、測試人員使用的IP、端口、數據幀測試結果通過/失敗失敗時的現象、錯誤代碼解決措施和復測結果這樣一來即使幾個月後項目升級回過頭看這些記錄也能快速定位“為什麼當時要這麼配置”。8. 一些實戰心得讓TCP通訊少走彎路做西門子PLC TCP通訊測試這幾年我總結了幾個特別想分享的點算不上什麼高深理論但都是實戰中驗證過管用的。第一測試腳本化。不要每次手動點“發送”要寫一個自動發送的小工具或者用PLC程序裡的循環計數器自動發送帶序號的數據幀。這樣測試半小時你就能通過序號是否連續判斷有沒有丟包、重複包。手動點幾下就宣布“測完了”那根本不算測完。第二重視字節序提前統一。很多跨項目通訊的問題最後查出來都是字節序或者數據類型長度不匹配。我的建議是在通訊數據表裡就明確標註每一位元的字節序、數據類型傳給對方確認後再動手。不要等聯調時才發現數值不對那時改程序、改配置的成本就高了。第三斷線重連測試一定要做。很多工程師只測“正常通訊”不測“異常恢復”。實際上現場最大的問題不是通訊建立不起來而是斷了之後起不來。你們一定要主動在測試時拔網線、重啟PLC、關閉對方設備模擬各種異常情況確認系統能在規定時間內自動恢復。第四連通性測試工具要搭配著用。ping用來測鏈路調試助手用來測應用層Wireshark用來測協議層。這三個工具各有側重哪一個都不能少。第五留好調試接口。在PLC程序裡留一個測試模式比如某個M位或者DB位置位後程序自動發送固定測試數據便於現場故障時快速判斷是PLC通訊問題還是外部設備問題。這個小技巧在後期維護中非常有用。TCP通訊本身的知識點並不複雜真正考驗人的是“把知識變成穩定可靠的工程實踐”。希望這篇測試筆記能幫你少踩一些坑。下次有人問你“TCP測試怎麼做”你就可以理直氣壯地告訴他先ping再調試助手再抓包最後做異常恢復測試一套下來穩了。
 软件包管理器的全方位认识)
