簡介在工業(yè)上位機開發(fā)中以C#為客戶端、MCGS昆侖通態(tài)為服務(wù)端的TCP通信是一類常見需求。這份范例代碼面向自動化集成、組態(tài)軟件二次開發(fā)的工程師提供讀取MCGS數(shù)據(jù)的完整樣例工程解決C#與昆侖通態(tài)觸摸屏及組態(tài)環(huán)境之間的網(wǎng)絡(luò)數(shù)據(jù)交換問題。壓縮包共三十六個文件體積約九十二KB包含九個C#核心代碼文件、四個文本說明、三個可執(zhí)行程序以及工程配置、資源文件、調(diào)試符號等覆蓋源碼、配置、運行與調(diào)試的典型文件類型可直接打開解決方案查看和修改。目前已有二千五百零四人學習下載適合有一定C#基礎(chǔ)、需要快速實現(xiàn)與MCGS通信的開發(fā)者。通過該范例可以掌握Socket通信的建立、連接與數(shù)據(jù)幀解析方法結(jié)合看板人機MCE文件和窗體應(yīng)用工程結(jié)構(gòu)還能了解上位機界面與組態(tài)畫面的聯(lián)動測試方式為后續(xù)接入實際設(shè)備或擴展多數(shù)據(jù)類型讀寫提供可直接復(fù)用的起點。1. 用 C# 捅穿 MCGS 的 TCP 黑匣子先想清楚三個問題做上位機開發(fā)的人遲早會撞上 MCGS昆侖通態(tài)觸摸屏前期用 USB 下載程序、用串口調(diào)試都沒問題一到產(chǎn)線就要走以太網(wǎng)。手頭這份「C# 與 MCGS 使用 TCP 通信范例代碼」真正的難點不在 C# 怎么寫 Socket而在三件事MCGS 組態(tài)里的設(shè)備通道怎么映射成 Modbus 寄存器地址報文按什么字節(jié)序解析斷線重連到底由誰負責。把這三件事想清楚TCP 通信基本一次通。這篇筆記適合兩類人一類是剛接手上位機開發(fā)、需要從零對接組態(tài)屏的從業(yè)者另一類是已經(jīng)在用串口或 OPC、想切到 TCP 又怕踩坑的開發(fā)者。先說結(jié)論MCGS 側(cè)的 TCP 配置遠比想象的瑣碎但摸清它的寄存器尋址規(guī)律后C# 側(cè)的代碼其實可以寫得很收斂一份請求函數(shù)加一份解析函數(shù)就能覆蓋九成場景。2. 從組態(tài)端開始MCGS 設(shè)備窗口與 TCP 參數(shù)配置2.1 設(shè)備通道與寄存器地址映射很多人拿到范例代碼先去改 C#結(jié)果連不上實際上第一道坎在組態(tài)軟件里。MCGS 里的「設(shè)備窗口」負責掛驅(qū)動、建通道、配變量。要點是先確定觸摸屏用的是「TCP/IP」驅(qū)動還是「Modbus TCP」驅(qū)動這兩者報文格式一樣但變量地址的組織方式有差別。范例里用的是 Modbus TCP 驅(qū)動因為它把通道地址直接暴露成 4x 區(qū)保持寄存器方便上位機用功能碼 03、06、16 去讀寫。添加設(shè)備后每個變量要綁定一個通道通道地址格式通常是4x開頭比如4x0001。這個4x不是擺設(shè)它告訴驅(qū)動這個變量映射到保持寄存器區(qū)。對應(yīng)的 Modbus 協(xié)議地址要換算成報文里的寄存器編號規(guī)則是報文地址 通道地址 - 40001也就是說4x0001對應(yīng)報文里的 0x00004x0010對應(yīng) 0x0009。C# 側(cè)構(gòu)造請求時寄存器地址寫的是 0 基地址不是組態(tài)里顯示的那個從 1 開始的地址。這個偏移關(guān)系是大多數(shù)聯(lián)調(diào)失敗的根源務(wù)必先確認清楚。2.2 TCP 服務(wù)端/客戶端與 IP 端口設(shè)置MCGS 的 TCP/IP 驅(qū)動有兩種工作模式觸摸屏做服務(wù)端上位機做客戶端主動連接或者觸摸屏做客戶端上位機開一個 TCP 服務(wù)端等它連上來。大多數(shù)產(chǎn)線場景選前者因為上位機程序啟動時機不確定而觸摸屏上電后應(yīng)該一直監(jiān)聽。范例代碼默認也是這個方案觸摸屏作為服務(wù)端監(jiān)聽 502 端口C# 程序作為客戶端發(fā)起連接。在 MCGS 的 TCP/IP 設(shè)備屬性里需要填寫本地 IP、端口號以及允許連接的遠程 IP。這里有一個容易被忽略的選項如果組態(tài)里勾選了「僅允許固定 IP 連接」而 C# 所在電腦的 IP 不在列表里連接會被直接拒絕表現(xiàn)是上位機發(fā)了 SYN 但觸摸屏不回應(yīng)。排查時先把這個選項放開等聯(lián)調(diào)通了再收緊。另外如果 C# 程序跑在虛擬機上注意虛擬機網(wǎng)卡和橋接模式否則 IP 在同一個物理網(wǎng)段也收不到包。2.3 變量聯(lián)動與讀寫權(quán)限配置建好通道后還要在 MCGS 的「實時數(shù)據(jù)庫」里建對應(yīng)的變量并把變量與通道關(guān)聯(lián)。這里建議把變量名、通道地址、數(shù)據(jù)類型整理成一張對照表C# 注釋里也保留同一份表否則后期加變量會亂。讀寫權(quán)限方面MCGS 里每個通道可以設(shè)置「只讀」「只寫」「讀寫」三種權(quán)限。上位機要讀數(shù)據(jù)通道至少要是只讀或讀寫要下發(fā)參數(shù)必須設(shè)為讀寫或只寫。如果 C# 寫入成功但觸摸屏端數(shù)值不變十有八九是通道權(quán)限沒放開而不是通信問題。提示聯(lián)調(diào)之前先把觸摸屏和電腦接到同一臺交換機關(guān)掉兩端防火墻用 ping 確認 IP 通。這一步能省掉后面至少兩小時排錯時間。3. C# 側(cè) TCP 連接Socket 還是 TcpClient參數(shù)怎么給3.1 連接超時與斷線重連范例代碼里可以只用最原始的 Socket也可以用封裝好的 TcpClient。我的習慣是直接用 Socket因為 TcpClient 的 Connect 方法在網(wǎng)絡(luò)不通時會卡很久超時控制不如 Socket 直觀。常見做法是用異步連接加等待句柄簡單可靠using System.Net.Sockets; using System.Net; using System.Threading; private static bool ConnectWithTimeout(Socket socket, IPEndPoint remote, int timeoutMs) { var result socket.BeginConnect(remote, null, null); // 發(fā)起異步連接 bool connected result.AsyncWaitHandle.WaitOne(timeoutMs, false); // 等待指定毫秒 if (connected) { socket.EndConnect(result); // 連接成功結(jié)束異步操作 return true; } socket.Close(); // 超時則關(guān)閉避免半連接殘留 return false; }這段代碼的價值在于把連接超時變成可控參數(shù)。BeginConnect不會阻塞調(diào)用線程WaitOne負責等結(jié)果timeoutMs在生產(chǎn)環(huán)境我一般給 3000 毫秒。EndConnect必須在連接成功后調(diào)用否則 Socket 會報「異步操作未完成」。超時后直接Close是必須的不然連接對象還掛在系統(tǒng)里下次重連時會繼續(xù)占用資源表現(xiàn)為端口被耗盡。斷線重連策略不要做成「斷了就立刻重連」那會讓觸摸屏疲于處理連接請求。我一般用遞增退避第一次等待 1 秒第二次 2 秒最大 30 秒封頂連續(xù)失敗 10 次后復(fù)位到 1 秒再來一輪。3.2 發(fā)送緩沖區(qū)與粘包處理Modbus TCP 報文很短一般不涉及大緩沖區(qū)設(shè)置。真正要注意的是接收端的粘包與半包問題。C# 的Receive每次返回的字節(jié)數(shù)不保證恰好是一個完整報文可能一次收到兩幀也可能只收到半幀。范例代碼里用MemoryStream做累積緩沖每次收到數(shù)據(jù)先追加再循環(huán)嘗試解析出一個完整幀private byte[] _buffer new byte[4096]; private MemoryStream _stream new MemoryStream(); private void OnDataReceived(byte[] data) { _stream.Write(data, 0, data.Length); // 新數(shù)據(jù)先寫入累積流 while (TryExtractFrame(_stream, out byte[] frame)) { ProcessFrame(frame); // 完整幀交給解析邏輯 } }粘包的處理核心是最外層循環(huán)只關(guān)心「能不能從累積流里取出一整幀」取不出來就等下一包而不是每次Receive都直接當成一個響應(yīng)去解析。TryExtractFrame內(nèi)部先讀 6 字節(jié)報文頭用報文頭里的字節(jié)長度字段算出總長再看累積流里夠不夠那么多字節(jié)夠就截取不夠就返回 false。3.3 報文構(gòu)造與 CRC 的誤區(qū)Modbus TCP 和 Modbus RTU 最大的區(qū)別是TCP 幀沒有 CRC 校驗校驗交給 TCP 協(xié)議棧報文格式也更緊湊。所以我見過有人把 RTU 的 CRC 計算代碼直接搬過來硬塞進 TCP 報文尾部結(jié)果觸摸屏返回非法報文錯誤。范例代碼里不需要任何 CRC 函數(shù)報文結(jié)構(gòu)是固定的 7 字節(jié) MBAP 頭加 PDU。構(gòu)造請求時只需關(guān)注三個字段事務(wù)標識符可用自增計數(shù)器、協(xié)議標識符固定 0x0000、長度字段高字節(jié) 0、低字節(jié)為后續(xù)字節(jié)數(shù)。很多新手在長度字段上翻車把整個報文長度寫進去了實際應(yīng)該寫「從單元標識符開始算起的字節(jié)數(shù)」也就是協(xié)議數(shù)據(jù)單元長度加 1。這個細節(jié)后續(xù)寫報文時會再具體展示。4. Modbus TCP 報文拆解與 C# 實現(xiàn)功能碼 03、06、16 的讀寫組合4.1 讀多個保持寄存器0x03的請求響應(yīng)拆包讀數(shù)據(jù)是上位機最頻繁的操作。功能碼 03 用于讀取連續(xù)多個保持寄存器在 MCGS 里也就是批量讀取 4x 區(qū)變量。請求報文只有 12 字節(jié)事務(wù)標識符占 2 字節(jié)、協(xié)議標識符占 2 字節(jié)、長度占 2 字節(jié)、單元標識符占 1 字節(jié)、功能碼占 1 字節(jié)、起始地址占 2 字節(jié)、寄存器數(shù)量占 2 字節(jié)。C# 構(gòu)造函數(shù)可以這樣寫private static byte[] BuildReadRequest(ushort transactionId, byte unitId, ushort startAddr, ushort count) { int length 6; // 單元標識符 功能碼 起始地址 數(shù)量 byte[] frame new byte[12]; frame[0] (byte)(transactionId 8); // 事務(wù)標識符高字節(jié) frame[1] (byte)(transactionId 0xFF); // 事務(wù)標識符低字節(jié) frame[2] 0x00; // 協(xié)議標識符高字節(jié)固定 0 frame[3] 0x00; // 協(xié)議標識符低字節(jié)固定 0 frame[4] (byte)(length 8); // 長度高字節(jié)此處恒為 0 frame[5] (byte)(length 0xFF); // 長度低字節(jié)6 frame[6] unitId; // 單元標識符通常為 1 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; }transactionId每次都加一目的是把同一時刻發(fā)出的多個請求和對應(yīng)響應(yīng)配對。unitId在觸摸屏默認配置里通常是 1但如果組態(tài)里改了站號這里必須跟著改。startAddr用第 2 章說的 0 基地址比如要讀組態(tài)里的4x0001這里傳 0 而不是 1。響應(yīng)報文首字節(jié)是單元標識符次字節(jié)是功能碼 0x03第三字節(jié)是字節(jié)計數(shù)數(shù)值等于寄存器數(shù)量乘以 2后面才是寄存器數(shù)據(jù)每個寄存器占 2 字節(jié)高字節(jié)在前。4.2 寫單個寄存器0x06與寫多個寄存器0x10下發(fā)的場景通常有兩種改一個參數(shù)、切換一個模式用功能碼 06 寫單個寄存器批量下發(fā)配方或設(shè)定值用功能碼 160x10寫多個連續(xù)寄存器。功能碼 06 的請求是 12 字節(jié)MBAP 頭加單元標識符加 0x06 加寄存器地址加寄存器值。功能碼 16 的請求會更長一些在地址和數(shù)量之后還要加一個字節(jié)計數(shù)字段然后才是數(shù)據(jù)區(qū)private static byte[] BuildWriteMultipleRequest(ushort transId, byte unitId, ushort startAddr, ushort[] values) { int byteCount values.Length * 2; byte[] frame new byte[13 byteCount]; // 13 字節(jié)頭 數(shù)據(jù)區(qū) frame[0] (byte)(transId 8); frame[1] (byte)(transId 0xFF); frame[2] 0x00; frame[3] 0x00; frame[4] (byte)((7 byteCount) 8); // 長度 單元標識符 功能碼 地址 數(shù)量 字節(jié)計數(shù) 數(shù)據(jù)區(qū) frame[5] (byte)((7 byteCount) 0xFF); frame[6] unitId; frame[7] 0x10; // 功能碼 16寫多個寄存器 frame[8] (byte)(startAddr 8); frame[9] (byte)(startAddr 0xFF); frame[10] (byte)(values.Length 8); frame[11] (byte)(values.Length 0xFF); frame[12] (byte)byteCount; for (int i 0; i values.Length; i) { frame[13 i * 2] (byte)(values[i] 8); // 數(shù)據(jù)高字節(jié) frame[14 i * 2] (byte)(values[i] 0xFF); // 數(shù)據(jù)低字節(jié) } return frame; }注意長度字段的計算這里7 byteCount包含了單元標識符、功能碼、起始地址、數(shù)量、字節(jié)計數(shù)和數(shù)據(jù)區(qū)。寫操作最大的坑是「寫成功了但值不對」多半是寄存器地址傳錯或者數(shù)據(jù)字節(jié)序和組態(tài)端不一致。MCGS 默認大端模式即高字節(jié)在前上面的代碼已經(jīng)按這個順序排列。如果組態(tài)里改成小端則需要把source 0xFF放到低位前面。4.3 數(shù)據(jù)格式轉(zhuǎn)換int、float、bool 與大小端陷阱MCGS 變量類型比寄存器數(shù)據(jù)類型多了一層映射。一個 32 位浮點數(shù)在 Modbus 里占兩個寄存器也就是 4 字節(jié)。問題是這兩個寄存器誰在前誰在后以及每個寄存器內(nèi)部的高低字節(jié)順序組態(tài)軟件里通常有「字節(jié)順序」和「字順序」兩個選項。范例代碼里最常見的組合是「單字小端 字序大端」即每個寄存器的低字節(jié)在前但兩個寄存器中高地址字在前。如果不確定先從觸摸屏組態(tài)里找出設(shè)備驅(qū)動的默認設(shè)置再對齊 C# 的解析代碼。private static float ReadFloat(byte[] response, int offset) { // 大端模式高字節(jié)在前高字在前 byte highWordHigh response[offset]; // 第一個寄存器高字節(jié) byte highWordLow response[offset 1]; // 第一個寄存器低字節(jié) byte lowWordHigh response[offset 2]; // 第二個寄存器高字節(jié) byte lowWordLow response[offset 3]; // 第二個寄存器低字節(jié) if (BitConverter.IsLittleEndian) { byte[] bytes { lowWordLow, lowWordHigh, highWordLow, highWordHigh }; return BitConverter.ToSingle(bytes, 0); } byte[] bigEndian { highWordHigh, highWordLow, lowWordHigh, lowWordLow }; return BitConverter.ToSingle(bigEndian, 0); }這段代碼的意圖是把收到的 4 字節(jié)組裝回 C# 環(huán)境下的 float。因為 C# 在本機通常是小端序直接BitConverter.ToSingle會把字節(jié)序弄反所以需要手動重新排列。offset指向響應(yīng)報文里第一個數(shù)據(jù)字節(jié)的位置即「單元標識符 功能碼 字節(jié)計數(shù)」之后。bool 類型通常占一個寄存器值非 0 即 true但要注意 MCGS 里可能用 0 和 1 之外的值表示狀態(tài)建議在 C# 側(cè)做歸一化判斷而不是直接比較等于 1。5. 避坑與 MCGS 聯(lián)調(diào)的七個血淚踩坑記錄5.1 現(xiàn)象上位機連接失敗觸摸屏沒反應(yīng)原因MCGS 設(shè)備窗口里沒啟用 TCP/IP 驅(qū)動或者驅(qū)動配好了但設(shè)備沒有處于「運行」狀態(tài)。觸摸屏只有進入運行環(huán)境后才開始監(jiān)聽端口在組態(tài)環(huán)境或停止運行時端口根本不打開。解決在觸摸屏上啟動運行環(huán)境用電腦命令行執(zhí)行telnet 屏IP 502能看到連接提示說明端口已開。如果 telnet 都連不上回到組態(tài)確認設(shè)備驅(qū)動狀態(tài)并在觸摸屏上查看系統(tǒng)日志里的通信記錄。5.2 現(xiàn)象連接成功但讀回來的數(shù)值全是 0且不變化原因寄存器地址偏移錯誤或者變量沒有綁定通道。MCGS 顯示地址和 Modbus 協(xié)議地址相差 14x0001對應(yīng)協(xié)議地址 0。如果 C# 里直接用 1 發(fā)起請求實際讀到的是 4x0002那個通道沒綁定變量自然返回 0。解決把 C# 的請求地址改回通道地址 - 40001并和組態(tài)里的通道表逐條核對?？梢栽谟|摸屏上臨時給某個變量賦一個固定非零值上位機如果能讀到這個值就證明地址映射正確。5.3 現(xiàn)象float 讀出來是天文數(shù)字int 讀出來有規(guī)律但不對原因字節(jié)序或者字序不匹配。組態(tài)端和 C# 端有兩層排列需要對齊寄存器內(nèi)部的字節(jié)高低順序、多個寄存器之間的字順序。任何一層不一致讀出來的二進制重組結(jié)果都是錯的。解決先用一個已知的簡單整數(shù)變量調(diào)通比如給變量賦 0x1234上位機讀回后打印原始字節(jié)看是12 34還是34 12。確定字節(jié)序后再處理字序int 沒問題但 float 異常時基本就是字序反了。范例代碼里已經(jīng)給出大端寫法按實際組態(tài)切換。5.4 現(xiàn)象寫入返回成功但觸摸屏畫面上的值沒變原因通道權(quán)限是只讀或者變量被組態(tài)畫面里的腳本持續(xù)改寫。MCGS 中如果同一變量在多個腳本里被賦值上位機寫入后很快又被腳本覆蓋。解決在組態(tài)里把目標通道的讀寫權(quán)限改為「讀寫」并檢查畫面腳本里是否有周期賦值邏輯。生產(chǎn)環(huán)境里這種「隱性寫入」最難發(fā)現(xiàn)排查時把觸摸屏畫面停掉單獨驗證通信是否正常。5.5 現(xiàn)象運行一段時間后通信中斷程序沒有報錯原因半開連接。觸摸屏重啟、網(wǎng)線瞬斷、交換機重啟都會讓 TCP 連接進入半開狀態(tài)C# 側(cè)不知道對端已死后續(xù)寫入失敗后才觸發(fā)異常但此時還想復(fù)用舊連接。解決為 Socket 設(shè)置讀寫超時比如ReceiveTimeout設(shè)為 2000 毫秒同時把斷線檢測放到獨立的看門狗線程里定時用功能碼 03 讀一個固定寄存器連續(xù)失敗 3 次就關(guān)閉連接并走重連流程。范例代碼里重連的退避策略也是為這個場景準備的。5.6 現(xiàn)象輪詢頻率很高時觸摸屏出現(xiàn)通信報警原因MCGS TCP 驅(qū)動對請求頻率有限制上位機以幾十毫秒間隔連續(xù)請求時觸摸屏來不及處理通信錯誤計數(shù)飆升。解決把輪詢周期從 50 毫秒改為 200 毫秒以上必要的話把多個地址合并成一次功能碼 03 批量讀取減少請求次數(shù)。觸摸屏不是 PLC它更擅長把數(shù)據(jù)展示給人看不適合當高速采集前端。5.7 現(xiàn)象返回異常幀功能碼是 0x83 或 0x90原因Modbus 異常響應(yīng)的功能碼是請求功能碼 0x80后面的異常碼能直接指出問題。0x83 表示功能碼 03 的異常響應(yīng)常見異常碼 0x02非法數(shù)據(jù)地址、0x03非法數(shù)據(jù)值、0x01非法功能碼。解決收到異常幀時打印異常碼再排查。0x02 多為寄存器地址越界0x03 多為寫入值超范圍。不要忽略異常幀直接丟棄它比超時有價值得多。6. 驗證與進階用自寫小工具回環(huán)測試三分鐘確認鏈路通不通范例代碼跑起來之前我習慣先做一個回環(huán)測試不接真實觸摸屏在電腦上自己起一個最簡單的 Modbus TCP 服務(wù)端模擬 MCGS 的響應(yīng)行為。這樣做的好處是把問題切成兩半——先證明 C# 客戶端邏輯正確再對接觸摸屏出問題時不會兩頭猜。測試工具不用太復(fù)雜核心就三件事監(jiān)聽 502 端口、接收請求、按功能碼回包。功能碼 03 返回若干個寄存器的固定值功能碼 06 和 16 原樣返回請求幀。用 C# 寫一個TcpListener在一分鐘內(nèi)就能搭好配合一個調(diào)試工具抓包看 C# 發(fā)出的報文和模擬端返回的報文是否對稱。這個習慣幫我擋掉過大量問題有一次對接時觸摸屏怎么都連不上回環(huán)測試證明客戶端代碼沒問題最后發(fā)現(xiàn)是組態(tài)里設(shè)備沒啟動。從那以后我每次聯(lián)調(diào)都強制走一遍回環(huán)測試先在本地把報文邏輯驗證完再拉到現(xiàn)場對接節(jié)省的時間遠比寫測試工具多。進階層面還有兩個習慣值得養(yǎng)成。第一個是給每條請求打日志記錄事務(wù)標識符、功能碼、起始地址、字節(jié)內(nèi)容、耗時和響應(yīng)狀態(tài)日志輸出成 CSV出問題時直接看最后一段。第二個是輪詢節(jié)奏分優(yōu)先級急停、狀態(tài)類變量用 100 毫秒周期溫度、壓力等慢變量用 500 毫秒到 1 秒周期配方下發(fā)只在用戶觸發(fā)時執(zhí)行。把讀寫分離到兩個獨立線程寫操作做超時控制讀操作失敗時只告警不阻塞下發(fā)的界面操作。這樣產(chǎn)線運行幾個月后依然不會因為通信問題拖垮上位機。希望幫到你。本文還有配套的精品資源點擊獲取