簡介該演示源碼基于C# WinForm編寫面向工控上位機(jī)與數(shù)控系統(tǒng)開發(fā)人員演示如何借助三菱官方通訊庫EZNCAUTLib實(shí)現(xiàn)與三菱CNC機(jī)床的數(shù)據(jù)交互解決設(shè)備數(shù)據(jù)采集、狀態(tài)讀取與指令下發(fā)等常見問題。包內(nèi)共145個文件以24個C#源文件與Visual Studio工程文件為核心附帶三菱通訊依賴庫、可運(yùn)行exe、資源配置及少量說明文檔壓縮后僅771KB結(jié)構(gòu)緊湊適合直接打開調(diào)試。當(dāng)前已有1128人學(xué)習(xí)/下載可幫助需要快速理解三菱CNC通訊協(xié)議封裝或進(jìn)行二次開發(fā)的工程師縮短預(yù)研周期。源碼重點(diǎn)設(shè)計(jì)了MitCom通訊封裝類通過事件機(jī)制向外傳遞告警等實(shí)時數(shù)據(jù)可直接參考初始化流程、事件綁定與Winform界面交互寫法并可在實(shí)際項(xiàng)目中復(fù)用其通訊框架。1. C# 與三菱 CNC 通訊WinForm 上位機(jī) Demo 到底能解決什么做上位機(jī)的人都知道C# 加 WinForm 是三菱 CNC 數(shù)據(jù)采集場景里最常見的一套組合但真正把通訊 Demo 跑通卡住的往往是協(xié)議細(xì)節(jié)而不是代碼本身。這套源碼解決的核心問題很直接讓一臺普通 PC 或工控機(jī)通過以太網(wǎng)與三菱 CNC 交換數(shù)據(jù)——讀坐標(biāo)、讀運(yùn)行狀態(tài)、下發(fā)啟動停止指令全部落到 WinForm 界面上。適合三類人來復(fù)用正在做產(chǎn)線數(shù)據(jù)采集卻不知道協(xié)議怎么開口的 C# 開發(fā)者要給 CNC 增加遠(yuǎn)程監(jiān)控畫面而沒有現(xiàn)成通訊代碼的電氣工程師以及想弄明白 MC 協(xié)議報文長什么樣的自動化新人。下面前幾章先把選型講清楚再給可運(yùn)行的代碼最后把現(xiàn)場常見的坑逐個拆掉。2. 通訊選型EZSocket、MC 協(xié)議與透傳哪條路更適合你的現(xiàn)場2.1 三菱 CNC 對外通訊的三條通道三菱 CNC 開放給上位機(jī)的數(shù)據(jù)通道實(shí)際能落地的就三類。第一類是官方工具鏈比如 EZSocket 這類 ActiveX 控件它把底層報文封裝好了上位機(jī)通過數(shù)據(jù) ID 直接讀坐標(biāo)、讀報警、讀程序號。優(yōu)點(diǎn)是不用操心幀格式缺點(diǎn)也很明顯COM 組件注冊、x86/x64 位數(shù)、.NET 版本兼容任何一個環(huán)節(jié)沒對上就起不來。第二類是用 MC 協(xié)議直接走 TCP 端口發(fā)報文這是很多 DEMO 源碼的首選也是本章重點(diǎn)。MC 協(xié)議本質(zhì)上是訪問 CNC 內(nèi)部的數(shù)據(jù)寄存器空間上位機(jī)自己拼幀、自己解析響應(yīng)沒有任何中間依賴部署就是一把裸 exe但代價是地址映射得自己對著手冊和設(shè)備側(cè)梯形圖確認(rèn)。第三類是文件級交互通過 FTP、共享目錄或者 CF 卡導(dǎo)入導(dǎo)出加工程序適合批量上下載程序不適合做實(shí)時的坐標(biāo)和狀態(tài)采集。很多第一次接觸三菱 CNC 的人會默認(rèn)官方控件是唯一方案真的到現(xiàn)場就會發(fā)現(xiàn)老設(shè)備上控件版本和系統(tǒng)不匹配反而是常態(tài)。我一般建議先看 CNC 型號和系統(tǒng)版本再看現(xiàn)場有沒有 PLC 梯形圖的修改權(quán)限如果兩者都受限制EZSocket 依然是第一選擇如果設(shè)備是近幾年交付的以太網(wǎng)功能選項(xiàng)齊全MC 協(xié)議直連更省心這也是這份 DEMO 源碼主走的路線。2.2 方案對比EZSocket、MC 協(xié)議、文件級交互怎么選對比項(xiàng)EZSocket 官方控件MC 協(xié)議 TCP 直連文件級交互開發(fā)量小控件封裝了數(shù)據(jù) ID中需要拼報文和解析小但只適合傳文件實(shí)時性好好差秒級以上部署依賴需要注冊 COM注意位數(shù)無依賴一把 exe 即可依賴 FTP 服務(wù)或共享目錄數(shù)據(jù)范圍官方定義的數(shù)據(jù) ID寄存器地址取決于梯形圖映射程序文件不涉及點(diǎn)位典型坑注冊失敗、Embed Interop 沖突地址映射不準(zhǔn)、字節(jié)序顛倒不適合讀坐標(biāo)、狀態(tài)從上表能看出來MC 協(xié)議是投入產(chǎn)出比最均衡的方案。它不依賴第三方組件協(xié)議幀結(jié)構(gòu)在網(wǎng)上和三菱的通訊手冊里都能查到對照只要 CNC 側(cè)把網(wǎng)絡(luò)參數(shù)打開就能建立連接。EZSocket 適合時間緊、數(shù)據(jù)點(diǎn)多、不想碰協(xié)議的場景但每次換現(xiàn)場機(jī)器都可能被 COM 注冊坑一次。文件級交互基本排除在實(shí)時監(jiān)控類需求之外。2.3 最小通訊單元MC 協(xié)議 3E 幀的讀取請求怎么拼MC 協(xié)議里常用的是 3E 幀二進(jìn)制模式讀字請求的幀結(jié)構(gòu)不算復(fù)雜理解它比背下來更重要。幀頭占據(jù)前兩個字節(jié)然后是網(wǎng)絡(luò)號、PC 號、IO 編號和站號這四段在單機(jī)直連場景下用默認(rèn)值即可。從監(jiān)視定時器之后才是真正跟業(yè)務(wù)相關(guān)的字段。下面給出一段 C# 構(gòu)建讀取請求幀的代碼private byte[] BuildReadFrame(ushort startAddr, ushort count) { using var ms new MemoryStream(); // 幀頭3E 幀二進(jìn)制模式固定為 D0 00 ms.Write(new byte[] { 0xD0, 0x00 }, 0, 2); ms.WriteByte(0x00); // 網(wǎng)絡(luò)號 ms.WriteByte(0xFF); // PC 號 ms.Write(new byte[] { 0x03, 0xFF }, 0, 2); // IO 編號固定值 ms.WriteByte(0x00); // 站號 // 請求數(shù)據(jù)長度從監(jiān)視定時器到幀尾的字節(jié)數(shù)讀字請求固定 11 ms.Write(new byte[] { 0x0B, 0x00 }, 0, 2); ms.Write(new byte[] { 0x10, 0x00 }, 0, 2); // 監(jiān)視定時器0x10 * 250ms 4 秒 ms.Write(new byte[] { 0x01, 0x04 }, 0, 2); // 指令0x0401 讀字 ms.Write(new byte[] { 0x00, 0x00 }, 0, 2); // 子指令按字訪問 // 起始地址 3 字節(jié)低字節(jié)在前 ms.WriteByte((byte)(startAddr 0xFF)); ms.WriteByte((byte)((startAddr 8) 0xFF)); ms.WriteByte(0x00); // 擴(kuò)展位D 設(shè)備置 0 // 讀取點(diǎn)數(shù) 2 字節(jié)低字節(jié)在前 ms.WriteByte((byte)(count 0xFF)); ms.WriteByte((byte)((count 8) 0xFF)); return ms.ToArray(); }這段代碼里請求數(shù)據(jù)長度算作 11 是很多人容易算錯的地方監(jiān)視定時器占 2 字節(jié)指令占 2 字節(jié)子指令占 2 字節(jié)起始地址占 3 字節(jié)讀取點(diǎn)數(shù)占 2 字節(jié)加起來正好 11不含幀頭。監(jiān)視定時器 0x0010 表示 16 個時間單位每個單位 250 毫秒也就是 4 秒這個值在長響應(yīng)場景下可以調(diào)大單位換算關(guān)系不變。startAddr 是字地址比如要讀 D100就傳 100按字地址而不是字節(jié)地址計(jì)算。count 是讀取的字?jǐn)?shù)建議控制在 64 字以內(nèi)部分系列批量讀取上限是 256 字超了會直接返回錯誤碼這個以 CNC 配套手冊為準(zhǔn)。擴(kuò)展位字節(jié)在 D 設(shè)備訪問時填 0如果以后要訪問文件寄存器 R 或擴(kuò)展繼電器這里可能不同遇到再說。3. 連接與讀取C# 里把坐標(biāo)、狀態(tài)讀回界面的具體寫法3.1 工程骨架與連接管理類 CncClient拿到這份 DEMO 源碼先別急著跑界面把通訊層剝出來看。核心類 CncClient 承擔(dān)了連接、讀寫、斷開的全部職責(zé)UI 層只跟它打交道。工程結(jié)構(gòu)上建議拆成三個文件CncClient.cs 管通訊AddressMap.cs 管地址映射MainForm.cs 管界面。這樣后面換機(jī)型只需要改地址映射不用動通訊代碼。public class CncClient : IDisposable { private TcpClient _tcp; private NetworkStream _stream; private readonly object _lock new object(); private readonly int _timeoutMs; public CncClient(int timeoutMs 3000) { _timeoutMs timeoutMs; } public void Connect(string ip, int port) { Dispose(); _tcp new TcpClient(); var task _tcp.ConnectAsync(ip, port); if (!task.Wait(_timeoutMs)) throw new TimeoutException($連接 {ip}:{port} 超時); _stream _tcp.GetStream(); _stream.ReadTimeout _timeoutMs; _stream.WriteTimeout _timeoutMs; } public void Dispose() { _stream?.Dispose(); _tcp?.Dispose(); } }Connect 方法里用 ConnectAsync 加 Wait 的方式實(shí)現(xiàn)超時控制比直接調(diào) Connect 好用后者在網(wǎng)絡(luò)不通時會卡住幾十秒。連接超時時間默認(rèn) 3 秒現(xiàn)場如果是跨交換機(jī)跨網(wǎng)段可以調(diào)到 5 秒但不要太大不然斷線后恢復(fù)會很慢。_lock 對象在讀寫方法里會用到確保輪詢線程和寫入線程不會同時操作流。3.2 讀坐標(biāo)按字讀取、字節(jié)序與比例尺坐標(biāo)數(shù)據(jù)在 CNC 側(cè)通常是字單位1 個字對應(yīng) 16 位有符號整數(shù)。很多 DEMO 第一次跑出來的坐標(biāo)是亂碼不是協(xié)議問題而是把無符號讀出來了。負(fù)坐標(biāo)在 -0.001mm 量級下會被讀成 65535 之類的正數(shù)看著就像脫韁了一樣。讀取并解析坐標(biāo)的完整方法如下public short[] ReadWords(ushort startAddr, ushort count) { byte[] frame BuildReadFrame(startAddr, count); lock (_lock) { _stream.Write(frame, 0, frame.Length); // 響應(yīng)頭幀頭2 網(wǎng)絡(luò)號1 PC號1 IO號2 站號1 7 字節(jié) byte[] header ReadExact(7); byte[] lenBuf ReadExact(2); int bodyLen BitConverter.ToUInt16(lenBuf, 0); byte[] body ReadExact(bodyLen); ushort endCode BitConverter.ToUInt16(body, 0); if (endCode ! 0x0000) throw new IOException($MC 返回錯誤碼 0x{endCode:X4}); int dataLen bodyLen - 2; short[] result new short[dataLen / 2]; for (int i 0; i result.Length; i) { result[i] BitConverter.ToInt16(body, 2 i * 2); } return result; } }ReadExact 是一個循環(huán)讀取的輔助方法因?yàn)?NetworkStream.Read 一次未必讀完指定長度必須循環(huán)。響應(yīng)里 bodyLen 包含了結(jié)束代碼的 2 字節(jié)所以要減掉才能得到數(shù)據(jù)區(qū)長度。讀取的數(shù)據(jù)按小端字節(jié)序解析成 short三菱的數(shù)據(jù)寄存器就是小端BitConverter.ToInt16 在 x86 和 x64 平臺上都符合。得到的 short 數(shù)組需要乘以比例尺才是真實(shí)物理量常見 CNC 最小輸入單位是 0.001mmD 寄存器里存的是 12345 就代表 12.345mm比例尺就是 0.001。這個值不要寫死放進(jìn)配置里不同軸可能不同。3.3 讀狀態(tài)狀態(tài)字的位解析運(yùn)行狀態(tài)和坐標(biāo)不一樣坐標(biāo)是多字?jǐn)?shù)據(jù)狀態(tài)一般是一個字里打包了多個開關(guān)量。比如 bit0 代表運(yùn)行中bit1 代表報警bit2 代表自動模式這種位定義通常靠 CNC 側(cè)梯形圖從系統(tǒng)變量搬運(yùn)到 D 寄存器。狀態(tài)字解析用枚舉加位邏輯最清晰[Flags] public enum CncStatus { None 0, Running 1 0, // bit0: 主軸運(yùn)行中 Alarm 1 1, // bit1: 有報警 AutoMode 1 2, // bit2: 自動模式 HomeComplete 1 3, // bit3: 回零完成 } public static CncStatus ParseStatus(short raw) { return (CncStatus)(raw 0x000F); }掩碼 0x000F 的意思是只取低 4 位高位可能在現(xiàn)場設(shè)備里另有定義不能貿(mào)然全量轉(zhuǎn)換。實(shí)際項(xiàng)目里位定義可能更多規(guī)范做法是先拉到 CNC 面板的 PLC 監(jiān)控頁看 D 寄存器每個 bit 的實(shí)際變化確認(rèn)之后再往枚舉里補(bǔ)。這種位解析代碼本身不復(fù)雜麻煩的是確認(rèn) bit 定義的過程所以 DEMO 里一定要保留這份枚舉定義和現(xiàn)場對照記錄。3.4 界面刷新定時器輪詢與跨線程安全WinForm 界面用 System.Windows.Forms.Timer 做定時輪詢是最省事的做法但坑也集中在 UI 線程上。網(wǎng)絡(luò) IO 是阻塞的如果直接在 Tick 事件里同步 ReadWords界面會卡到通訊完成才恢復(fù)一旦斷線就可能白屏好幾秒。輪詢代碼要防重入并借助 BeginInvoke 回到 UI 線程更新控件private bool _busy; private void timer_Tick(object sender, EventArgs e) { if (_busy) return; _busy true; try { short[] data _client.ReadWords(0x0010, 6); BeginInvoke(new Action(() { lblX.Text (data[0] * 0.001m).ToString(F3); lblY.Text (data[1] * 0.001m).ToString(F3); lblZ.Text (data[2] * 0.001m).ToString(F3); lblStatus.Text CncStatus.ParseStatus(data[3]).ToString(); })); } catch (Exception ex) { BeginInvoke(new Action(() lblStatus.Text 通訊異常 ex.Message)); } finally { _busy false; } }_busy 標(biāo)志位是為了防止上一次周期還沒結(jié)束下一次 Tick 又進(jìn)來導(dǎo)致網(wǎng)絡(luò)流同時被多個線程操作。BeginInvoke 的作用是把控件更新排到 UI 線程隊(duì)列不在后臺線程直接操作 Label。輪詢間隔一般取 200 到 500 毫秒太短會增加 CNC 側(cè)通訊負(fù)擔(dān)太長界面上看著不實(shí)時。還要注意 Timer 的 Interval 在界面失去焦點(diǎn)時不會停下窗體最小化時建議主動停止輪詢省得無謂占網(wǎng)。4. 寫入與下發(fā)程序號、啟停指令與報文日志的落地細(xì)節(jié)4.1 寫請求幀與讀請求幀的三處不對稱寫操作比讀操作復(fù)雜的地方在于幀結(jié)構(gòu)調(diào)整了三處指令碼從 0x0401 換成 0x1401請求數(shù)據(jù)長度不再是固定 11而是要在末尾追加要寫入的數(shù)據(jù)。構(gòu)建寫幀的代碼如下private byte[] BuildWriteFrame(ushort startAddr, short[] values) { int bodyLen 11 values.Length * 2; using var ms new MemoryStream(); ms.Write(new byte[] { 0xD0, 0x00 }, 0, 2); ms.WriteByte(0x00); ms.WriteByte(0xFF); ms.Write(new byte[] { 0x03, 0xFF }, 0, 2); ms.WriteByte(0x00); ms.Write(new byte[] { (byte)(bodyLen 0xFF), (byte)(bodyLen 8) }, 0, 2); ms.Write(new byte[] { 0x10, 0x00 }, 0, 2); ms.Write(new byte[] { 0x01, 0x14 }, 0, 2); // 指令 0x1401 寫字 ms.Write(new byte[] { 0x00, 0x00 }, 0, 2); // 子指令仍按字 ms.WriteByte((byte)(startAddr 0xFF)); ms.WriteByte((byte)((startAddr 8) 0xFF)); ms.WriteByte(0x00); ms.WriteByte((byte)(values.Length 0xFF)); ms.WriteByte((byte)((values.Length 8) 0xFF)); foreach (short v in values) { ms.WriteByte((byte)(v 0xFF)); ms.WriteByte((byte)((v 8) 0xFF)); } return ms.ToArray(); }第一處不對稱是請求數(shù)據(jù)長度跟隨寫入數(shù)據(jù)變化忘了改就會導(dǎo)致 CNC 端解析錯位。第二處是響應(yīng)解析邏輯不同寫響應(yīng)只有結(jié)束代碼沒有數(shù)據(jù)區(qū)所以讀完 bodyLen 后直接判斷結(jié)束代碼即可。第三處是寫入操作必須確認(rèn)結(jié)束代碼為 0x0000 才能算成功有些設(shè)備在自動運(yùn)行模式下拒絕寫入會返回錯誤碼這一層異常必須向上拋不能靜默吞掉。4.2 下發(fā)程序號與啟停指令的時序MC 協(xié)議本身只能寫寄存器不能直接發(fā)「啟動加工」這種語義指令?，F(xiàn)場常見做法是在 CNC 內(nèi)置 PLC 梯形圖里定義好控制字比如 D200 寫入 1 表示請求自動運(yùn)行梯形圖讀到后觸發(fā)啟動信號。這才解釋得通為什么很多 DEMO 源碼里下發(fā)程序號和一個控制字是分開寫的。通用時序如下// 第一步切換到編輯或自動模式 _client.WriteWords(0x00C8, new short[] { 1 }); // 模式控制字置 1 Thread.Sleep(50); // 第二步寫入目標(biāo)程序號 _client.WriteWords(0x00CA, new short[] { 100 }); // 程序號 O0100 // 第三步給出啟動脈沖置 1 再置 0 _client.WriteWords(0x00CC, new short[] { 1 }); Thread.Sleep(100); _client.WriteWords(0x00CC, new short[] { 0 });這里 D 區(qū)地址是示意值真實(shí)項(xiàng)目必須根據(jù)現(xiàn)場梯形圖定義來定。我把模式切換、程序號、啟動分三個步驟的目的就是讓每一步可驗(yàn)證在 CNC 面板上觀察當(dāng)前模式是否切換、程序號是否正確、啟動是否有動作。三步之間加延時是緩解總線競爭不是必須但加了能減少偶發(fā)失敗。如果發(fā)完啟動指令后 CNC 沒有動先看模式是否為自動再看機(jī)床是否處于復(fù)位狀態(tài)報警狀態(tài)下啟動指令會被忽略。4.3 報文日志把黑匣子變成可回放的記錄通訊聯(lián)調(diào)最怕的是現(xiàn)場復(fù)現(xiàn)不了問題。每次收發(fā)都留報文日志后面排查能少走很多彎路。一個樸素的日志記錄方法把 TX 和 RX 的十六進(jìn)制報文連同時間戳寫進(jìn)文本文件public void LogExchange(byte[] tx, byte[] rx, string remark) { var sb new StringBuilder(); sb.AppendLine($[{DateTime.Now:HH:mm:ss.fff}] {remark}); sb.AppendLine($TX: {Convert.ToHexString(tx)}); if (rx ! null rx.Length 0) sb.AppendLine($RX: {Convert.ToHexString(rx)}); File.AppendAllText(_logPath, sb.ToString()); }Convert.ToHexString 是 .NET 5 以上的寫法如果 DEMO 工程跑在 .NET Framework 4.x 上要用 BitConverter.ToString 然后去掉中間的橫線。日志記錄放到 CncClient 內(nèi)部調(diào)用每次 ReadWords 和 WriteWords 都自動記不要等出問題再去加。有了報文日志回放比對就很簡單把出問題時的 TX 幀和正常時的 TX 幀放在一起逐字節(jié)看往往就是請求長度的低字節(jié)寫錯或者地址移位一個字節(jié)。5. 避坑與排查連接失敗、數(shù)值紊亂、UI 卡死的五個真實(shí)場景5.1 連接超時但 CNC 側(cè)無響應(yīng)現(xiàn)象PC ping 得通 CNC 的 IP但程序 Connect 每次都超時CNC 面板上網(wǎng)絡(luò)狀態(tài)看著也是正常的。原因ping 通只代表 IP 層可達(dá)不代表業(yè)務(wù)端口開放。CNC 的以太網(wǎng)功能一般分好幾個服務(wù)MC 協(xié)議服務(wù)如果沒有單獨(dú)開啟端口就是關(guān)閉狀態(tài)。另外 PC 的防火墻也會攔截入站響應(yīng)尤其是 Windows 10 以上系統(tǒng)默認(rèn)阻止外部連接。解決三步走。第一步用 Test-NetConnection 指令驗(yàn)證端口通不通第二步到 CNC 面板的網(wǎng)絡(luò)參數(shù)畫面確認(rèn) MC 協(xié)議服務(wù)處于啟用狀態(tài)端口號和程序里一致第三步臨時關(guān)閉 PC 防火墻測試通了再放行相關(guān)端口。從那以后我每次聯(lián)機(jī)都強(qiáng)制走一遍 IP、端口、服務(wù)開關(guān)三層確認(rèn)沒再被這個問題絆過腳。5.2 坐標(biāo)數(shù)值是負(fù)的或者被放大了一百倍現(xiàn)象讀出來的 X 坐標(biāo)顯示 -32768或者明明在原點(diǎn)附近卻顯示 64000 多和面板實(shí)際值完全對不上。原因這兩個現(xiàn)象根因不同。負(fù)數(shù)偏置通常是把有符號數(shù)按無符號解析比如 -0.5 在 short 里是 0xFFFE按 ushort 讀出來就是 65534再乘比例尺自然離譜。放大一百倍通常是比例尺搞錯CNC 最小輸入單位是 0.001mm但有人用 0.01 去乘或者反過來。解決解析 short 時用 BitConverter.ToInt16不要用 ToUInt16比例尺先寫死 0.001 驗(yàn)證一個已知坐標(biāo)準(zhǔn)了再改成配置值。還有極少數(shù)設(shè)備里坐標(biāo)用 BCD 碼存儲這時候不能直接 short 轉(zhuǎn)換要額外寫 BCD 轉(zhuǎn)十進(jìn)制函數(shù)。判斷方法很笨但是有效在 CNC 面板上手動搖到一個整數(shù)位置比如 12.000mm讀出來如果是 0x1200 這類形態(tài)八成是 BCD。5.3 程序號永遠(yuǎn)讀到 0現(xiàn)象連接正常其他寄存器都讀得出唯獨(dú)程序號這一項(xiàng)一直是 0。原因程序號不在普通的 D 寄存器區(qū)很多型號要通過系統(tǒng)變量或者在特定條件下才能讀取比如 CNC 處于復(fù)位狀態(tài)時程序號緩沖區(qū)是空的。還有可能讀的 D 地址雖然存在但梯形圖根本沒有把程序號搬運(yùn)到那里讀到的只是上電默認(rèn)值 0。解決先去 CNC 面板的手動頁面確認(rèn)當(dāng)前程序號確實(shí)有值再到 PLC 監(jiān)控頁面看目標(biāo) D 地址的內(nèi)容。如果面板有值而 D 地址是 0問題就在梯形圖側(cè)需要找電氣程序確認(rèn)搬運(yùn)邏輯如果 D 地址有值而程序讀到 0才輪到排查通訊解析。順序不能反過來否則會被錯誤地帶偏方向。5.4 輪詢一多 UI 就卡死現(xiàn)象界面跑十幾分鐘后操作變得遲鈍點(diǎn)按鈕半天沒反應(yīng)偶爾出現(xiàn)「未響應(yīng)」標(biāo)題。原因最常見的是在 UI 線程同步執(zhí)行了網(wǎng)絡(luò)讀TCP 超時期間界面完全阻塞。另一種隱蔽情況是 Timer 間隔太短網(wǎng)絡(luò)慢的時候上次請求還沒返回下個 Tick 又進(jìn)來導(dǎo)致多個請求堆積在流里響應(yīng)錯位最后拋異常異常邏輯里又同步寫文件進(jìn)一步卡 UI。解決同步讀改成 Task.Run 包裹或者把讀操作放到獨(dú)立的后臺線程隊(duì)列里只放最新一幀數(shù)據(jù)。Timer 間隔不要低于 200 毫秒并且保持 _busy 防重入。寫日志改為異步線程或者限制頻率不要在異常處理里做文件追加這種高延遲操作。5.5 EZSocket COM 組件注冊與位數(shù)翻車現(xiàn)象方案選型用了 EZSocket代碼編譯沒問題運(yùn)行時卻報「未在注冊表中標(biāo)記為允許交互操作」或者找不到 COM 類工廠。原因EZSocket 是 32 位 ActiveX 控件如果程序以 x64 編譯進(jìn)程無法加載 32 位 COM 組件。另外每次換機(jī)器部署目標(biāo)機(jī)沒有執(zhí)行過 regsvr32 注冊組件根本不存在。還有 Visual Studio 引用了互操作程序集但沒有正確設(shè)置 Embed Interop Types運(yùn)行時互操作解析失敗。解決項(xiàng)目平臺目標(biāo)強(qiáng)制改 x86AnyCPU 在 64 位系統(tǒng)上會踩雷部署時用管理員權(quán)限執(zhí)行 regsvr32 注冊控件路徑引用屬性里把 Embed Interop Types 設(shè)為 False讓互操作程序集作為獨(dú)立 DLL 輸出。如果現(xiàn)場不允許裝 COM 組件老老實(shí)實(shí)切回 MC 協(xié)議方案不用在這條路上硬耗。6. 進(jìn)階收尾把輪詢改成事件驅(qū)動這個 Demo 才算真正能上線6.1 用 Channel 替代 Timer 的輪詢Timer 輪詢在 30 分鐘內(nèi)的聯(lián)調(diào)沒問題但跑到一個通宵就容易暴露問題周期漂移、偶發(fā)重入、CPU 空轉(zhuǎn)。稍微往上走一步用 System.Threading.Channel 做生產(chǎn)者和消費(fèi)者模型。讀線程往 Channel 里丟數(shù)據(jù)界面線程訂閱后更新控件通訊頻率和界面刷新頻率完全解耦ChannelCncFrame _channel Channel.CreateBoundedCncFrame(16); async Task ReadLoopAsync() { while (!_ct.IsCancellationRequested) { var frame await Task.Run(() _client.ReadWords(_addr, 6)); await _channel.Writer.WriteAsync(frame, _ct); await Task.Delay(200, _ct); } } async Task UILoopAsync() { await foreach (var frame in _channel.Reader.ReadAllAsync(_ct)) { lblX.Text (frame[0] * 0.001m).ToString(F3); } }有界 Channel 容量設(shè) 16寫入超過容量時生產(chǎn)端自動等待防止 CNC 響應(yīng)快而界面刷新慢時數(shù)據(jù)無限堆積吃掉內(nèi)存。6.2 斷線重連與心跳讓程序隔夜不跑飛上線之后遇到最多的不是首次連接失敗而是半夜網(wǎng)絡(luò)閃斷后程序一直停在異常狀態(tài)。斷線重連不要無腦 while 循環(huán)間隔做指數(shù)退避從 1 秒起步翻倍到 30 秒封頂避免斷線期間瘋狂刷連接請求把 CNC 側(cè)通訊模塊打滿。同時每隔幾秒發(fā)一次讀取請求當(dāng)心跳連續(xù)失敗三次觸發(fā)重連邏輯。這個機(jī)制加上后基本上能做到第二天早上打開界面數(shù)據(jù)依然是新的不用人工干預(yù)。6.3 一個收尾習(xí)慣先驗(yàn)證協(xié)議再寫界面這份 DEMO 我已經(jīng)反復(fù)拆過好幾輪最想囑咐一句的是拿到源碼后先把 CncClient 單獨(dú)拎出來寫一個控制臺小工程只讀坐標(biāo)跑通了再往 WinForm 上拖控件。界面和通訊混在一起調(diào)試時你很難分清是界面事件寫錯了還是報文拼錯了。從那以后我每次做設(shè)備通訊都強(qiáng)制走一遍這個步驟先把協(xié)議這層黑匣子驗(yàn)證透再考慮按鈕和表格怎么擺。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取