：Modbus TCP 通信從調(diào)試到穩(wěn)定讀寫)
簡介這份資源面向具備一定C#基礎、希望打通上位機與工業(yè)控制設備數(shù)據(jù)鏈路的開發(fā)者圍繞C#與匯川PLC之間的通信展開重點解決TCP/IP連接建立、Modbus協(xié)議報文構造與寄存器讀寫等實際問題適合自動化系統(tǒng)集成、工控上位機開發(fā)等場景的初中級學習者參考。壓縮包共624個文件、約214.54MB包含12個cs源碼、12個vb示例、6個sln解決方案及配套csproj工程文件另有大量h、cpp、lib、dll等底層庫與編譯產(chǎn)物以及docx說明、xml配置和txt日志便于對照源碼理解通信庫的調(diào)用方式。資源已有582人學習下載。內(nèi)容覆蓋C#網(wǎng)絡編程、Modbus主從架構與ASCII/RTU/TCP傳輸模式、匯川PLC地址映射與命令集配置并涉及CRC校驗、異常處理與超時重試、通信性能優(yōu)化及WinForms/WPF界面集成等要點讀者可據(jù)此搭建可運行的通信示例掌握請求響應解析與排錯思路。1. 從一條產(chǎn)線調(diào)試現(xiàn)場說起C# 對接匯川 PLC 到底難在哪產(chǎn)線聯(lián)調(diào)最怕的不是 PLC 邏輯寫錯而是上位機連不上。某次現(xiàn)場一臺工控機跑著 C# 寫的上位機網(wǎng)線插好、IP 也配了點“連接”就是沒反應換成調(diào)試軟件卻能讀到數(shù)據(jù)。折騰半天才發(fā)現(xiàn)問題出在端口號和站號上——調(diào)試軟件默認走的是另一套參數(shù)而代碼里寫死的是另一套。這類“玄學”問題在 C# 與匯川 PLC 通信里太常見了。這份示例資源要解決的就是讓 C# 上位機穩(wěn)定讀寫匯川 PLC 的寄存器、線圈和狀態(tài)位。它適合兩類人一是剛接手產(chǎn)線上位機、需要快速跑通通信的 C# 開發(fā)者二是想把通信層封裝成可復用模塊、后續(xù)接 MES 或數(shù)據(jù)采集的老手。下面按“協(xié)議選型 → 代碼落地 → 排錯避坑 → 進階驗證”的順序拆開講每一步都能照著復現(xiàn)。2. 協(xié)議選型與連接參數(shù)先把 Modbus TCP 這條鏈路理清楚匯川 PLC 的以太網(wǎng)通信主流走的是 Modbus TCP。它把 Modbus 的 RTU 幀塞進 TCP 載荷里去掉了 CRC 校驗靠 TCP 本身保證可靠性。對 C# 來說這意味著不需要額外驅(qū)動用System.Net.Sockets就能直接發(fā)字節(jié)流。選它的理由很實在協(xié)議公開、調(diào)試工具多、跨平臺工控機上跑 .NET Framework 或 .NET 8 都行。但“能通”和“穩(wěn)定”是兩回事。連接參數(shù)里藏著幾個必須對齊的點錯一個就連不上或者讀回臟數(shù)據(jù)。2.1 端口、站號與寄存器地址的三組對齊Modbus TCP 默認端口是 502但匯川部分型號的以太網(wǎng)口會映射到其他端口現(xiàn)場一定要以 PLC 側(cè)配置為準。站號Unit ID在 TCP 模式下通常填 1可有些網(wǎng)關或雙機場景會改成別的值代碼里寫死 1 就可能被拒。寄存器地址是最容易翻車的地方。匯川 PLC 的軟元件地址如 D100、M10和 Modbus 寄存器地址之間有一個偏移映射常見做法是 D 寄存器從 0 開始對應保持寄存器 40001 之后的區(qū)域但不同系列偏移規(guī)則不完全一樣。我一般會先拿調(diào)試軟件讀一個已知值記下它實際發(fā)出的寄存器地址再把這個地址寫進代碼而不是憑手冊硬推。參數(shù)常見取值說明協(xié)議Modbus TCP匯川以太網(wǎng)口主流支持端口502以 PLC 側(cè)實際配置為準站號1網(wǎng)關或多機場景需核對功能碼03/06/16讀保持寄存器、寫單寄存器、寫多寄存器超時10003000 ms產(chǎn)線網(wǎng)絡抖動大時適當放寬2.2 用 Socket 手搓一幀請求看清字節(jié)序再動手不急著上庫先用最原始的方式發(fā)一幀能幫你把協(xié)議吃透。下面這段代碼構造一個讀保持寄存器的請求讀站號 1、起始地址 0、數(shù)量 2。using System; using System.Net.Sockets; byte[] BuildReadHolding(int unitId, ushort startAddr, ushort count) { // Modbus TCP 報文頭事務號(2) 協(xié)議號(2) 長度(2) 站號(1) byte[] frame new byte[12]; frame[0] 0x00; frame[1] 0x01; // 事務號任意響應會原樣帶回 frame[2] 0x00; frame[3] 0x00; // 協(xié)議號固定 0 frame[4] 0x00; frame[5] 0x06; // 后續(xù)字節(jié)數(shù) 站號1 PDU5 frame[6] (byte)unitId; // 站號 frame[7] 0x03; // 功能碼讀保持寄存器 frame[8] (byte)(startAddr 8); // 起始地址高字節(jié) frame[9] (byte)(startAddr 0xFF); // 起始地址低字節(jié) frame[10] (byte)(count 8); // 數(shù)量高字節(jié) frame[11] (byte)(count 0xFF); // 數(shù)量低字節(jié) return frame; } using var client new TcpClient(); client.Connect(192.168.1.10, 502); // PLC 實際 IP 與端口 var stream client.GetStream(); var req BuildReadHolding(1, 0, 2); stream.Write(req, 0, req.Length); byte[] resp new byte[256]; int n stream.Read(resp, 0, resp.Length); Console.WriteLine($收到 {n} 字節(jié)功能碼 {resp[7]:X2});邏輯上分三層報文頭負責事務匹配和長度聲明PDU 里的功能碼決定操作類型地址和數(shù)量按大端序排列。參數(shù)說明unitId填 PLC 站號startAddr是 Modbus 寄存器地址而非軟元件編號count一次別超過 125 個寄存器否則部分設備會直接回異常碼。響應里resp[7]是功能碼若最高位為 1如 0x83說明是異常響應resp[8]就是異常碼常見 0x02 是地址非法、0x03 是數(shù)量超限。2.3 封裝成可復用類把連接、重連、超時收進一個殼手搓幀適合理解協(xié)議真上產(chǎn)線得封裝。我一般會做一個ModbusTcpClient類內(nèi)部持有TcpClient對外暴露ReadHolding、WriteSingle、WriteMultiple三個方法連接狀態(tài)用IsConnected屬性暴露重連邏輯放在調(diào)用方或定時器里。public class ModbusTcpClient : IDisposable { private TcpClient _tcp; private NetworkStream _stream; private readonly string _ip; private readonly int _port; private readonly int _timeoutMs; public ModbusTcpClient(string ip, int port 502, int timeoutMs 2000) { _ip ip; _port port; _timeoutMs timeoutMs; } public bool Connect() { try { _tcp new TcpClient(); var task _tcp.ConnectAsync(_ip, _port); if (!task.Wait(_timeoutMs)) return false; // 連接超時保護 _stream _tcp.GetStream(); _stream.ReadTimeout _timeoutMs; _stream.WriteTimeout _timeoutMs; return true; } catch { return false; } } public ushort[] ReadHolding(byte unitId, ushort start, ushort count) { var req BuildReadHolding(unitId, start, count); _stream.Write(req, 0, req.Length); byte[] head ReadExact(7); // 先讀 7 字節(jié)頭 int len (head[4] 8) | head[5]; // 頭里聲明的后續(xù)長度 byte[] body ReadExact(len - 1); // 再讀剩余部分 if ((body[0] 0x80) ! 0) throw new Exception($異常碼 {body[1]:X2}); int byteCount body[1]; var result new ushort[byteCount / 2]; for (int i 0; i result.Length; i) result[i] (ushort)((body[2 i * 2] 8) | body[3 i * 2]); return result; } private byte[] ReadExact(int n) { byte[] buf new byte[n]; int off 0; while (off n) { int r _stream.Read(buf, off, n - off); if (r 0) throw new IOException(連接被對端關閉); off r; } return buf; } public void Dispose() { _stream?.Dispose(); _tcp?.Dispose(); } }這里的關鍵是ReadExactTCP 是流式協(xié)議一次Read不保證讀滿必須循環(huán)讀到指定長度否則解析會錯位。Connect里用Wait加超時避免網(wǎng)絡不通時界面卡死。參數(shù)上timeoutMs建議 2000 起步產(chǎn)線交換機負載高時調(diào)到 3000。寫操作同理功能碼 06 寫單寄存器、16 寫多寄存器注意寫多寄存器時字節(jié)數(shù)要按“數(shù)量×2”填。3. 讀寫寄存器與線圈把軟元件映射成 C# 里的強類型協(xié)議通了下一步是把 PLC 里的 D、M、X、Y 這些軟元件映射成 C# 里能直接用的變量。這一步做得好上層業(yè)務代碼就不用關心字節(jié)序和地址偏移做得糙后面每加一個點位都要改通信層。3.1 D 寄存器與 M 線圈的地址換算表匯川 PLC 的軟元件和 Modbus 地址之間不是一一對應常見映射關系如下表。注意這只是常見做法具體型號要以手冊或調(diào)試軟件實測為準。軟元件類型Modbus 區(qū)域常見起始地址讀寫功能碼D0Dn數(shù)據(jù)寄存器保持寄存器003 / 06 / 16M0Mn輔助繼電器線圈001 / 05 / 15X0Xn輸入離散輸入002只讀Y0Yn輸出線圈001 / 05 / 15換算時最容易錯的是“軟元件編號”和“Modbus 地址”混用。比如 D100 不一定對應寄存器地址 100有的系列會整體偏移。我的習慣是先在調(diào)試軟件里讀 D100抓包看它實際請求的地址再把這個地址寫進配置表而不是在代碼里做加減。3.2 批量讀寫的分塊策略與字節(jié)序處理一次讀太多寄存器PLC 可能回異?；蝽憫兟３Ｒ娮龇ㄊ前?100 個寄存器一塊切分循環(huán)讀取再拼接。字節(jié)序方面Modbus 寄存器內(nèi)部是大端但 32 位浮點數(shù)跨兩個寄存器時有的設備高字在前、有的低字在前讀回來要按實際順序拼。// 分塊讀取 0299 共 300 個保持寄存器 var all new Listushort(); for (ushort start 0; start 300; start 100) { ushort count (ushort)Math.Min(100, 300 - start); all.AddRange(client.ReadHolding(1, start, count)); } // 兩個寄存器拼一個 float注意字序 float ToFloat(ushort high, ushort low) { byte[] b new byte[4]; BitConverter.GetBytes(high).CopyTo(b, 0); BitConverter.GetBytes(low).CopyTo(b, 2); if (BitConverter.IsLittleEndian) Array.Reverse(b); return BitConverter.ToSingle(b, 0); }分塊大小 100 是經(jīng)驗值既不會觸發(fā)數(shù)量上限又能減少往返次數(shù)。ToFloat里先按大端拼字節(jié)再轉(zhuǎn)若現(xiàn)場讀出的浮點數(shù)明顯不對比如變成極小值或 NaN多半是字序反了把high和low對調(diào)再試。線圈讀寫類似功能碼 01 讀、05 寫單個、15 寫多個讀回來按位解析第 0 位對應起始地址那個線圈。3.3 用定時器做輪詢別讓界面線程背鍋上位機要實時刷新數(shù)據(jù)常見做法是開一個后臺線程或System.Threading.Timer按固定周期讀一批點位讀到后更新緩存界面只讀緩存。千萬別在 UI 線程里同步調(diào)通信方法網(wǎng)絡一抖界面就假死。private readonly object _lock new object(); private ushort[] _cache Array.Emptyushort(); var timer new System.Threading.Timer(_ { try { var data client.ReadHolding(1, 0, 50); lock (_lock) { _cache data; } // 只換引用讀側(cè)無鎖競爭 } catch (Exception ex) { // 記錄日志標記連接異常交給重連邏輯 Console.WriteLine($輪詢失敗{ex.Message}); } }, null, 0, 500); // 500ms 一輪輪詢周期 500ms 適合大多數(shù)監(jiān)控場景點位多時降到 1000ms避免把 PLC 通信口打滿。緩存用引用替換而不是逐元素拷貝讀側(cè)加鎖時間極短。異常不要吞掉至少記日志并置一個連接狀態(tài)標志重連邏輯根據(jù)這個標志決定是否重建連接。4. 避坑與排查連不上、讀回臟數(shù)據(jù)、斷線重連的現(xiàn)場記錄通信層寫完只是開始現(xiàn)場跑起來才是真正的考驗。下面幾條是反復踩過的坑按“現(xiàn)象 → 原因 → 解決”記下來遇到時能少走彎路。4.1 現(xiàn)象連接成功但讀回全 0 或異常碼 0x02原因通常是寄存器地址算錯或者站號不對。有的 PLC 在 TCP 模式下站號必須與配置一致填錯時設備會回異常而不是斷開。解決先用調(diào)試軟件讀同一地址抓包對比請求幀里的站號和地址字段逐字節(jié)核對確認地址偏移規(guī)則后把映射表固化成配置不要散落在代碼里。4.2 現(xiàn)象偶發(fā)讀到半截數(shù)據(jù)解析錯位這是典型的 TCP 粘包/半包問題。一次Read可能只拿到報文頭的一部分直接按固定長度解析就會錯位。解決嚴格按報文頭里的長度字段循環(huán)讀滿像前面ReadExact那樣讀到 0 字節(jié)說明對端關閉要觸發(fā)重連而不是繼續(xù)解析。4.3 現(xiàn)象運行幾小時后連接假死重啟程序才恢復原因多是網(wǎng)絡閃斷后TcpClient處于半開狀態(tài)Read一直阻塞或返回 0 卻沒被處理。解決設置ReadTimeout/WriteTimeout捕獲IOException后主動Dispose舊連接并重建輪詢線程里加一個“連續(xù)失敗 N 次則重連”的計數(shù)器N 取 3 比較穩(wěn)。4.4 現(xiàn)象寫寄存器成功但 PLC 側(cè)數(shù)值沒變先確認寫的是不是保持寄存器、功能碼對不對再確認 PLC 程序里有沒有對該寄存器做覆蓋寫。有些場景下 HMI 和上位機同時寫同一地址后寫的覆蓋先寫的。解決寫之前讀一次確認當前值寫之后回讀校驗失敗則重試一次并記錄避免“以為寫成功”的假象。4.5 現(xiàn)象多線程同時讀寫導致響應串包多個線程共用一個NetworkStream且沒有加鎖請求和響應會交錯。解決通信層內(nèi)部加一把鎖保證“發(fā)一幀、收一幀”原子完成或者每個連接只由一個輪詢線程使用其他線程通過隊列提交請求。我一般選后者結構更清晰。5. 進階驗證用回環(huán)測試和抓包把通信層釘死通信層交付前我習慣做兩件事一是本地回環(huán)測試二是在真實鏈路上抓包核對?；丨h(huán)測試不依賴 PLC用一個本地 TCP 服務端模擬響應能驗證解析邏輯和異常分支抓包則能看清實際發(fā)出的每一幀地址、站號、功能碼一目了然。回環(huán)測試可以這樣搭起一個TcpListener監(jiān)聽本地端口收到請求后按協(xié)議拼一個響應回去重點覆蓋正常響應、異常響應、半包三種情況。半包場景手動把響應拆成兩次發(fā)送驗證ReadExact是否還能正確拼回。抓包用常見的網(wǎng)絡分析工具過濾目標 IP 和 502 端口對照代碼里的請求幀逐字段看地址偏移對不對、站號有沒有被改一眼就能看出來。驗證項方法通過標準正常讀回環(huán)返回合法響應解析出的寄存器值與預期一致異常響應回環(huán)返回 0x83 異常碼拋出帶異常碼的異常不崩潰半包響應分兩次發(fā)送仍能拼出完整幀斷線重連中途關閉服務端計數(shù)觸發(fā)重連恢復后繼續(xù)讀有個細節(jié)值得單獨說浮點數(shù)和 32 位整數(shù)跨寄存器時字序問題在回環(huán)測試里就要覆蓋到別等到現(xiàn)場才發(fā)現(xiàn)讀出來是天文數(shù)字。我一般會在回環(huán)里準備兩組字序的樣本確認代碼能按配置切換。從那以后我每次交付通信模塊都強制走一遍“回環(huán) 抓包 斷線重連”三件套哪怕工期再緊也不省這一步——現(xiàn)場返工的成本遠比多花半天驗證高。希望幫到你。本文還有配套的精品資源點擊獲取 C# 對接匯川 PLC 實戰(zhàn)：Modbus TCP 通信從調(diào)試到穩(wěn)定讀寫
簡介這份資源面向具備一定C#基礎、希望打通上位機與工業(yè)控制設備數(shù)據(jù)鏈路的開發(fā)者圍繞C#與匯川PLC之間的通信展開重點解決TCP/IP連接建立、Modbus協(xié)議報文構造與寄存器讀寫等實際問題適合自動化系統(tǒng)集成、工控上位機開發(fā)等場景的初中級學習者參考。壓縮包共624個文件、約214.54MB包含12個cs源碼、12個vb示例、6個sln解決方案及配套csproj工程文件另有大量h、cpp、lib、dll等底層庫與編譯產(chǎn)物以及docx說明、xml配置和txt日志便于對照源碼理解通信庫的調(diào)用方式。資源已有582人學習下載。內(nèi)容覆蓋C#網(wǎng)絡編程、Modbus主從架構與ASCII/RTU/TCP傳輸模式、匯川PLC地址映射與命令集配置并涉及CRC校驗、異常處理與超時重試、通信性能優(yōu)化及WinForms/WPF界面集成等要點讀者可據(jù)此搭建可運行的通信示例掌握請求響應解析與排錯思路。1. 從一條產(chǎn)線調(diào)試現(xiàn)場說起C# 對接匯川 PLC 到底難在哪產(chǎn)線聯(lián)調(diào)最怕的不是 PLC 邏輯寫錯而是上位機連不上。某次現(xiàn)場一臺工控機跑著 C# 寫的上位機網(wǎng)線插好、IP 也配了點“連接”就是沒反應換成調(diào)試軟件卻能讀到數(shù)據(jù)。折騰半天才發(fā)現(xiàn)問題出在端口號和站號上——調(diào)試軟件默認走的是另一套參數(shù)而代碼里寫死的是另一套。這類“玄學”問題在 C# 與匯川 PLC 通信里太常見了。這份示例資源要解決的就是讓 C# 上位機穩(wěn)定讀寫匯川 PLC 的寄存器、線圈和狀態(tài)位。它適合兩類人一是剛接手產(chǎn)線上位機、需要快速跑通通信的 C# 開發(fā)者二是想把通信層封裝成可復用模塊、后續(xù)接 MES 或數(shù)據(jù)采集的老手。下面按“協(xié)議選型 → 代碼落地 → 排錯避坑 → 進階驗證”的順序拆開講每一步都能照著復現(xiàn)。2. 協(xié)議選型與連接參數(shù)先把 Modbus TCP 這條鏈路理清楚匯川 PLC 的以太網(wǎng)通信主流走的是 Modbus TCP。它把 Modbus 的 RTU 幀塞進 TCP 載荷里去掉了 CRC 校驗靠 TCP 本身保證可靠性。對 C# 來說這意味著不需要額外驅(qū)動用System.Net.Sockets就能直接發(fā)字節(jié)流。選它的理由很實在協(xié)議公開、調(diào)試工具多、跨平臺工控機上跑 .NET Framework 或 .NET 8 都行。但“能通”和“穩(wěn)定”是兩回事。連接參數(shù)里藏著幾個必須對齊的點錯一個就連不上或者讀回臟數(shù)據(jù)。2.1 端口、站號與寄存器地址的三組對齊Modbus TCP 默認端口是 502但匯川部分型號的以太網(wǎng)口會映射到其他端口現(xiàn)場一定要以 PLC 側(cè)配置為準。站號Unit ID在 TCP 模式下通常填 1可有些網(wǎng)關或雙機場景會改成別的值代碼里寫死 1 就可能被拒。寄存器地址是最容易翻車的地方。匯川 PLC 的軟元件地址如 D100、M10和 Modbus 寄存器地址之間有一個偏移映射常見做法是 D 寄存器從 0 開始對應保持寄存器 40001 之后的區(qū)域但不同系列偏移規(guī)則不完全一樣。我一般會先拿調(diào)試軟件讀一個已知值記下它實際發(fā)出的寄存器地址再把這個地址寫進代碼而不是憑手冊硬推。參數(shù)常見取值說明協(xié)議Modbus TCP匯川以太網(wǎng)口主流支持端口502以 PLC 側(cè)實際配置為準站號1網(wǎng)關或多機場景需核對功能碼03/06/16讀保持寄存器、寫單寄存器、寫多寄存器超時10003000 ms產(chǎn)線網(wǎng)絡抖動大時適當放寬2.2 用 Socket 手搓一幀請求看清字節(jié)序再動手不急著上庫先用最原始的方式發(fā)一幀能幫你把協(xié)議吃透。下面這段代碼構造一個讀保持寄存器的請求讀站號 1、起始地址 0、數(shù)量 2。using System; using System.Net.Sockets; byte[] BuildReadHolding(int unitId, ushort startAddr, ushort count) { // Modbus TCP 報文頭事務號(2) 協(xié)議號(2) 長度(2) 站號(1) byte[] frame new byte[12]; frame[0] 0x00; frame[1] 0x01; // 事務號任意響應會原樣帶回 frame[2] 0x00; frame[3] 0x00; // 協(xié)議號固定 0 frame[4] 0x00; frame[5] 0x06; // 后續(xù)字節(jié)數(shù) 站號1 PDU5 frame[6] (byte)unitId; // 站號 frame[7] 0x03; // 功能碼讀保持寄存器 frame[8] (byte)(startAddr 8); // 起始地址高字節(jié) frame[9] (byte)(startAddr 0xFF); // 起始地址低字節(jié) frame[10] (byte)(count 8); // 數(shù)量高字節(jié) frame[11] (byte)(count 0xFF); // 數(shù)量低字節(jié) return frame; } using var client new TcpClient(); client.Connect(192.168.1.10, 502); // PLC 實際 IP 與端口 var stream client.GetStream(); var req BuildReadHolding(1, 0, 2); stream.Write(req, 0, req.Length); byte[] resp new byte[256]; int n stream.Read(resp, 0, resp.Length); Console.WriteLine($收到 {n} 字節(jié)功能碼 {resp[7]:X2});邏輯上分三層報文頭負責事務匹配和長度聲明PDU 里的功能碼決定操作類型地址和數(shù)量按大端序排列。參數(shù)說明unitId填 PLC 站號startAddr是 Modbus 寄存器地址而非軟元件編號count一次別超過 125 個寄存器否則部分設備會直接回異常碼。響應里resp[7]是功能碼若最高位為 1如 0x83說明是異常響應resp[8]就是異常碼常見 0x02 是地址非法、0x03 是數(shù)量超限。2.3 封裝成可復用類把連接、重連、超時收進一個殼手搓幀適合理解協(xié)議真上產(chǎn)線得封裝。我一般會做一個ModbusTcpClient類內(nèi)部持有TcpClient對外暴露ReadHolding、WriteSingle、WriteMultiple三個方法連接狀態(tài)用IsConnected屬性暴露重連邏輯放在調(diào)用方或定時器里。public class ModbusTcpClient : IDisposable { private TcpClient _tcp; private NetworkStream _stream; private readonly string _ip; private readonly int _port; private readonly int _timeoutMs; public ModbusTcpClient(string ip, int port 502, int timeoutMs 2000) { _ip ip; _port port; _timeoutMs timeoutMs; } public bool Connect() { try { _tcp new TcpClient(); var task _tcp.ConnectAsync(_ip, _port); if (!task.Wait(_timeoutMs)) return false; // 連接超時保護 _stream _tcp.GetStream(); _stream.ReadTimeout _timeoutMs; _stream.WriteTimeout _timeoutMs; return true; } catch { return false; } } public ushort[] ReadHolding(byte unitId, ushort start, ushort count) { var req BuildReadHolding(unitId, start, count); _stream.Write(req, 0, req.Length); byte[] head ReadExact(7); // 先讀 7 字節(jié)頭 int len (head[4] 8) | head[5]; // 頭里聲明的后續(xù)長度 byte[] body ReadExact(len - 1); // 再讀剩余部分 if ((body[0] 0x80) ! 0) throw new Exception($異常碼 {body[1]:X2}); int byteCount body[1]; var result new ushort[byteCount / 2]; for (int i 0; i result.Length; i) result[i] (ushort)((body[2 i * 2] 8) | body[3 i * 2]); return result; } private byte[] ReadExact(int n) { byte[] buf new byte[n]; int off 0; while (off n) { int r _stream.Read(buf, off, n - off); if (r 0) throw new IOException(連接被對端關閉); off r; } return buf; } public void Dispose() { _stream?.Dispose(); _tcp?.Dispose(); } }這里的關鍵是ReadExactTCP 是流式協(xié)議一次Read不保證讀滿必須循環(huán)讀到指定長度否則解析會錯位。Connect里用Wait加超時避免網(wǎng)絡不通時界面卡死。參數(shù)上timeoutMs建議 2000 起步產(chǎn)線交換機負載高時調(diào)到 3000。寫操作同理功能碼 06 寫單寄存器、16 寫多寄存器注意寫多寄存器時字節(jié)數(shù)要按“數(shù)量×2”填。3. 讀寫寄存器與線圈把軟元件映射成 C# 里的強類型協(xié)議通了下一步是把 PLC 里的 D、M、X、Y 這些軟元件映射成 C# 里能直接用的變量。這一步做得好上層業(yè)務代碼就不用關心字節(jié)序和地址偏移做得糙后面每加一個點位都要改通信層。3.1 D 寄存器與 M 線圈的地址換算表匯川 PLC 的軟元件和 Modbus 地址之間不是一一對應常見映射關系如下表。注意這只是常見做法具體型號要以手冊或調(diào)試軟件實測為準。軟元件類型Modbus 區(qū)域常見起始地址讀寫功能碼D0Dn數(shù)據(jù)寄存器保持寄存器003 / 06 / 16M0Mn輔助繼電器線圈001 / 05 / 15X0Xn輸入離散輸入002只讀Y0Yn輸出線圈001 / 05 / 15換算時最容易錯的是“軟元件編號”和“Modbus 地址”混用。比如 D100 不一定對應寄存器地址 100有的系列會整體偏移。我的習慣是先在調(diào)試軟件里讀 D100抓包看它實際請求的地址再把這個地址寫進配置表而不是在代碼里做加減。3.2 批量讀寫的分塊策略與字節(jié)序處理一次讀太多寄存器PLC 可能回異?；蝽憫兟３Ｒ娮龇ㄊ前?100 個寄存器一塊切分循環(huán)讀取再拼接。字節(jié)序方面Modbus 寄存器內(nèi)部是大端但 32 位浮點數(shù)跨兩個寄存器時有的設備高字在前、有的低字在前讀回來要按實際順序拼。// 分塊讀取 0299 共 300 個保持寄存器 var all new Listushort(); for (ushort start 0; start 300; start 100) { ushort count (ushort)Math.Min(100, 300 - start); all.AddRange(client.ReadHolding(1, start, count)); } // 兩個寄存器拼一個 float注意字序 float ToFloat(ushort high, ushort low) { byte[] b new byte[4]; BitConverter.GetBytes(high).CopyTo(b, 0); BitConverter.GetBytes(low).CopyTo(b, 2); if (BitConverter.IsLittleEndian) Array.Reverse(b); return BitConverter.ToSingle(b, 0); }分塊大小 100 是經(jīng)驗值既不會觸發(fā)數(shù)量上限又能減少往返次數(shù)。ToFloat里先按大端拼字節(jié)再轉(zhuǎn)若現(xiàn)場讀出的浮點數(shù)明顯不對比如變成極小值或 NaN多半是字序反了把high和low對調(diào)再試。線圈讀寫類似功能碼 01 讀、05 寫單個、15 寫多個讀回來按位解析第 0 位對應起始地址那個線圈。3.3 用定時器做輪詢別讓界面線程背鍋上位機要實時刷新數(shù)據(jù)常見做法是開一個后臺線程或System.Threading.Timer按固定周期讀一批點位讀到后更新緩存界面只讀緩存。千萬別在 UI 線程里同步調(diào)通信方法網(wǎng)絡一抖界面就假死。private readonly object _lock new object(); private ushort[] _cache Array.Emptyushort(); var timer new System.Threading.Timer(_ { try { var data client.ReadHolding(1, 0, 50); lock (_lock) { _cache data; } // 只換引用讀側(cè)無鎖競爭 } catch (Exception ex) { // 記錄日志標記連接異常交給重連邏輯 Console.WriteLine($輪詢失敗{ex.Message}); } }, null, 0, 500); // 500ms 一輪輪詢周期 500ms 適合大多數(shù)監(jiān)控場景點位多時降到 1000ms避免把 PLC 通信口打滿。緩存用引用替換而不是逐元素拷貝讀側(cè)加鎖時間極短。異常不要吞掉至少記日志并置一個連接狀態(tài)標志重連邏輯根據(jù)這個標志決定是否重建連接。4. 避坑與排查連不上、讀回臟數(shù)據(jù)、斷線重連的現(xiàn)場記錄通信層寫完只是開始現(xiàn)場跑起來才是真正的考驗。下面幾條是反復踩過的坑按“現(xiàn)象 → 原因 → 解決”記下來遇到時能少走彎路。4.1 現(xiàn)象連接成功但讀回全 0 或異常碼 0x02原因通常是寄存器地址算錯或者站號不對。有的 PLC 在 TCP 模式下站號必須與配置一致填錯時設備會回異常而不是斷開。解決先用調(diào)試軟件讀同一地址抓包對比請求幀里的站號和地址字段逐字節(jié)核對確認地址偏移規(guī)則后把映射表固化成配置不要散落在代碼里。4.2 現(xiàn)象偶發(fā)讀到半截數(shù)據(jù)解析錯位這是典型的 TCP 粘包/半包問題。一次Read可能只拿到報文頭的一部分直接按固定長度解析就會錯位。解決嚴格按報文頭里的長度字段循環(huán)讀滿像前面ReadExact那樣讀到 0 字節(jié)說明對端關閉要觸發(fā)重連而不是繼續(xù)解析。4.3 現(xiàn)象運行幾小時后連接假死重啟程序才恢復原因多是網(wǎng)絡閃斷后TcpClient處于半開狀態(tài)Read一直阻塞或返回 0 卻沒被處理。解決設置ReadTimeout/WriteTimeout捕獲IOException后主動Dispose舊連接并重建輪詢線程里加一個“連續(xù)失敗 N 次則重連”的計數(shù)器N 取 3 比較穩(wěn)。4.4 現(xiàn)象寫寄存器成功但 PLC 側(cè)數(shù)值沒變先確認寫的是不是保持寄存器、功能碼對不對再確認 PLC 程序里有沒有對該寄存器做覆蓋寫。有些場景下 HMI 和上位機同時寫同一地址后寫的覆蓋先寫的。解決寫之前讀一次確認當前值寫之后回讀校驗失敗則重試一次并記錄避免“以為寫成功”的假象。4.5 現(xiàn)象多線程同時讀寫導致響應串包多個線程共用一個NetworkStream且沒有加鎖請求和響應會交錯。解決通信層內(nèi)部加一把鎖保證“發(fā)一幀、收一幀”原子完成或者每個連接只由一個輪詢線程使用其他線程通過隊列提交請求。我一般選后者結構更清晰。5. 進階驗證用回環(huán)測試和抓包把通信層釘死通信層交付前我習慣做兩件事一是本地回環(huán)測試二是在真實鏈路上抓包核對?；丨h(huán)測試不依賴 PLC用一個本地 TCP 服務端模擬響應能驗證解析邏輯和異常分支抓包則能看清實際發(fā)出的每一幀地址、站號、功能碼一目了然。回環(huán)測試可以這樣搭起一個TcpListener監(jiān)聽本地端口收到請求后按協(xié)議拼一個響應回去重點覆蓋正常響應、異常響應、半包三種情況。半包場景手動把響應拆成兩次發(fā)送驗證ReadExact是否還能正確拼回。抓包用常見的網(wǎng)絡分析工具過濾目標 IP 和 502 端口對照代碼里的請求幀逐字段看地址偏移對不對、站號有沒有被改一眼就能看出來。驗證項方法通過標準正常讀回環(huán)返回合法響應解析出的寄存器值與預期一致異常響應回環(huán)返回 0x83 異常碼拋出帶異常碼的異常不崩潰半包響應分兩次發(fā)送仍能拼出完整幀斷線重連中途關閉服務端計數(shù)觸發(fā)重連恢復后繼續(xù)讀有個細節(jié)值得單獨說浮點數(shù)和 32 位整數(shù)跨寄存器時字序問題在回環(huán)測試里就要覆蓋到別等到現(xiàn)場才發(fā)現(xiàn)讀出來是天文數(shù)字。我一般會在回環(huán)里準備兩組字序的樣本確認代碼能按配置切換。從那以后我每次交付通信模塊都強制走一遍“回環(huán) 抓包 斷線重連”三件套哪怕工期再緊也不省這一步——現(xiàn)場返工的成本遠比多花半天驗證高。希望幫到你。本文還有配套的精品資源點擊獲取