簡介面向三菱CNC數(shù)采開發(fā)與自動化調(diào)試場景的C#示例工程適合具備一定C#基礎(chǔ)、希望將機床數(shù)據(jù)接入上位機或業(yè)務(wù)系統(tǒng)的工程師參考也可作為自動化技術(shù)愛好者學(xué)習(xí)數(shù)控通訊流程的入門材料。內(nèi)容圍繞與三菱數(shù)控系統(tǒng)建立連接、采集加工參數(shù)與設(shè)備狀態(tài)、處理錯誤日志等需求展開并說明配合安裝A2.exe的作用幫助理解Demo運行前提、通訊接口調(diào)用與數(shù)據(jù)交換方式。壓縮包約3.52MB文件總數(shù)暫無有效值類型明細上游未給出預(yù)覽顯示含參考手冊PDF與SimCNC-master仿真源碼目錄可用于對照通訊協(xié)議、搭建無實機測試環(huán)境并驗證采集邏輯。已有626人學(xué)習(xí)適合借此梳理連接建立、數(shù)據(jù)解析、異常處理與調(diào)試排錯思路為后續(xù)上位機集成提供參考。1. 從一臺 M800 的網(wǎng)口說起這份 Demo 能省掉哪一半工作量很多人以為三菱CNC數(shù)采最難的是連不上實際在現(xiàn)場把線插好、IP 配好ping 通了真正耗時間的是后面那一段坐標怎么讀、報警號怎么對上文本、采集跑一夜內(nèi)存漲到幾個 G、換一臺系統(tǒng)版本不一樣的機臺又得重調(diào)。這份帶 C# 源碼的三菱CNC數(shù)據(jù)采集 Demo價值不在演示能讀到數(shù)而在它把會話建立、周期采集、數(shù)據(jù)落地、斷線重連這幾段骨架先搭好了你拿到手是把字段換成自己車間的不是從零畫架構(gòu)圖。適合兩類人手上有一批 M70/M80 系列機臺、想自己做一套輕量數(shù)采的自動化工程師以及接了小項目、需要一份能跑通的 C# 三菱CNC數(shù)采參考實現(xiàn)的外包開發(fā)者。它不解決跨品牌統(tǒng)一建模也不替你做 MES 對接邊界先講清楚后面才好判斷哪部分能直接用、哪部分必須自己補。2. 采集鏈路選型EZSocket、MC 協(xié)議與 MTConnect 三條路怎么選動手寫第一行代碼之前最該花時間的是把數(shù)據(jù)從哪個口子出來定下來。三菱CNC的數(shù)據(jù)出口不止一個選錯了后面寫多少代碼都是白搭。這一章把 CNC 側(cè)數(shù)據(jù)和 PLC 側(cè)數(shù)據(jù)的邊界劃清再把三條常見接入路線擺到一張表里對比最后給出這份 Demo 的工程分層方便你判斷它是能直接改還是只能當參考。2.1 CNC 數(shù)據(jù)與 PLC 數(shù)據(jù)先劃清邊界三菱CNC系統(tǒng)里其實住著兩個世界。一個是 NC 世界軸機械坐標、絕對坐標、相對坐標、主軸實際轉(zhuǎn)速、進給速度、當前執(zhí)行的程序號、刀具補償號、報警號與報警文本、伺服負載。這些數(shù)據(jù)由 NC 內(nèi)核維護走廠商提供的 NC 數(shù)據(jù)訪問接口最直接字段語義明確不用你去猜某個寄存器是第幾軸。另一個是 PLC 世界卡盤夾緊/松開、防護門開關(guān)、三色燈狀態(tài)、加工計數(shù)、外部急停鏈路、上下料機構(gòu)的握手信號。這些本質(zhì)上是梯形圖里的軟元件走 MC 協(xié)議讀 D/M/X/Y 更合適。把這兩個世界混在一個采集周期里是新手最常見的結(jié)構(gòu)性問題。NC 接口一次調(diào)用返回的是結(jié)構(gòu)化對象PLC 側(cè)返回的是一段連續(xù)的字節(jié)數(shù)組兩者的失敗模式、超時特征、刷新頻率都不一樣。我一般的做法是在采集層就分成兩個獨立的采集器各自有獨立的周期和獨立的健康狀態(tài)只在數(shù)據(jù)落地時按machine_id timestamp對齊。這樣某一側(cè)卡住了另一側(cè)還能繼續(xù)跑不會整條鏈路一起啞掉。還有一處容易忽略NC 側(cè)的坐標數(shù)據(jù)是有生命周期概念的。程序運行中、程序停止、急停、復(fù)位同名字段的可用性不一樣。有些實現(xiàn)在急停狀態(tài)下讀絕對坐標會返回上一次的緩存值看著像正常數(shù)據(jù)其實已經(jīng)失真。所以采集器里必須同時抓一個運行狀態(tài)字段落地時一起寫進去后面做數(shù)據(jù)分析的人才知道這條記錄該不該信。2.2 三條接入路線的成本對照下面這張表是我自己在幾個模擬項目里反復(fù)對比后沉淀下來的參數(shù)取值來自實際調(diào)試經(jīng)驗具體到你的機臺型號和選件配置會有出入看趨勢就行。維度EZSocket / NC 數(shù)據(jù)訪問庫MC 協(xié)議裸寫3E 幀MTConnect接入形態(tài)廠商提供的 .NET/COM 組件C# 直接引用自己拼二進制幀走 TCP/UDPHTTP XML輪詢 Agent數(shù)據(jù)粒度軸、主軸、報警、程序號等語義字段軟元件級D/M/X/Y 任意地址按設(shè)備模型定義的 DataItem單機接入工作量低半天能讀到第一條坐標中幀格式和響應(yīng)解析要自己寫高需要部署 Agent 并做映射跨品牌能力無綁定單一品牌無各品牌協(xié)議不同強標準模型額外授權(quán)通常需要官方運行庫/選件無只要網(wǎng)口開放Agent 側(cè)一般開源典型故障版本不匹配、位寬不匹配端口不通、字節(jié)序搞反Agent 掉線、映射字段缺失適合場景單品牌車間、快速出結(jié)果補采 PLC 側(cè)信號、機床無 NC 接口多品牌混線、要對接上層平臺選型判斷其實很簡單車間里只有一個品牌的機臺優(yōu)先走 NC 數(shù)據(jù)訪問庫因為它把第幾軸的第幾個坐標這種語義問題替你解決了如果還要采門、燈、卡盤這些外圍信號再疊一層 MC 協(xié)議補采只有當車間里同時存在多個品牌、上層平臺又要求統(tǒng)一模型時才值得為 MTConnect 付出那份額外的部署和映射成本。別為了架構(gòu)先進在一臺機臺上堆三套協(xié)議維護成本會把省下來的時間全吃掉。提示MC 協(xié)議是否開放、走 TCP 還是 UDP、端口號是多少取決于機臺的網(wǎng)絡(luò)參數(shù)設(shè)定不同選件配置下默認值可能不同。動手前先在機臺側(cè)確認一遍別拿網(wǎng)上抄來的端口硬試。2.3 Demo 工程結(jié)構(gòu)與依賴清單這份 Demo 的源碼結(jié)構(gòu)是典型的三層適配層、采集層、落地層。適配層把廠商 API 關(guān)在門內(nèi)對外只暴露一個自定義接口采集層負責(zé)周期調(diào)度和狀態(tài)機落地層負責(zé)緩沖和批量寫入。這個分法不新鮮但對數(shù)采這種廠商 API 隨時可能換版本的場景特別管用——哪天換了一臺系統(tǒng)版本不同的機臺你只需要再寫一個適配器實現(xiàn)采集層一行不用動。依賴清單不長但要一次配齊.NET Framework 4.7.2 或以上走 COM 互操作時我更傾向 Framework踩的坑少、廠商的通信運行庫、一個數(shù)據(jù)庫驅(qū)動、一個日志庫。工程里建議單獨建一個Libs目錄放廠商 DLL并且把復(fù)制到輸出目錄設(shè)成 true否則調(diào)試時經(jīng)常出現(xiàn)設(shè)計器里能引用、運行時報找不到模塊的玄學(xué)問題。下面是最小可跑的分層骨架把接口先立住后面所有代碼都往里填。// 適配層對外契約所有廠商差異都在實現(xiàn)類里消化 public interface ICncChannel : IDisposable { bool IsOpen { get; } void Open(); // 建立會話內(nèi)部做重試 CncSnapshot ReadSnapshot(); // 一次讀全量避免多次往返 } // 采集層只認這個結(jié)構(gòu)體不認廠商類型 public sealed class CncSnapshot { public DateTime TimestampUtc { get; set; } public string MachineId { get; set; } public double[] AxisPositions { get; set; } // 按軸號順序單位 mm public double SpindleSpeed { get; set; } // rpm public double FeedRate { get; set; } // mm/min public int ProgramNo { get; set; } public int AlarmNo { get; set; } // 0 表示無報警 public int RunState { get; set; } // 1 運行 2 暫停 3 急停 4 復(fù)位 }ICncChannel里刻意把Open和讀取分開是為了讓采集層能自己控制重連節(jié)奏——如果Open寫在構(gòu)造函數(shù)里一旦網(wǎng)絡(luò)抖動你連重試的入口都沒有。ReadSnapshot一次性返回全量而不是提供GetAxis(i)這種細粒度方法是因為走網(wǎng)絡(luò)協(xié)議的接口每次調(diào)用都是一次往返十個字段調(diào)十次周期直接被拖垮。TimestampUtc用 UTC 存展示層再轉(zhuǎn)本地時區(qū)這一條后面第 5 章還會專門講它是時區(qū)問題的后悔藥。3. 把 Demo 跑起來從運行庫注冊到第一條軸坐標環(huán)境這一關(guān)勸退過不少人不是因為難是因為報錯信息太含糊。這一章按環(huán)境準備 → 會話建立 → 采集循環(huán)的順序走一遍每步給出可執(zhí)行的命令或代碼并說明失敗時該看哪里。跟著走完你應(yīng)該能在自己的機臺上看到第一條真實的軸坐標。3.1 環(huán)境準備與網(wǎng)絡(luò)連通性驗證第一步是把運行庫裝對。廠商的通信組件通常是 32 位和 64 位兩套你的宿主進程是哪個位數(shù)就必須裝對應(yīng)那一套混裝的表現(xiàn)是編譯通過、運行時拋類型加載異常。工程屬性里把目標平臺從Any CPU改成明確的x64或x86別留默認值這是最常見的翻車點之一。裝完之后用管理員權(quán)限注冊一次路徑按你實際安裝位置改。# 以管理員身份運行32 位進程用 SysWOW64 下的 regsvr32 regsvr32 C:\Program Files (x86)\Common Files\Vendor\Comm\EzSocket.dll # 確認注冊成功查注冊表里有沒有對應(yīng)的 ProgID reg query HKCR\EzSocketLib.EzSocket /s # 確認進程位數(shù)與庫位數(shù)一致 corflags C:\YourApp\bin\Debug\YourApp.exe三條命令各管一件事第一條把 COM 組件寫進注冊表第二條驗證寫入成功查不到就說明路徑不對或者權(quán)限不夠第三條確認宿主進程的位數(shù)標記32BITREQ表示必須跑在 32 位下。第三條規(guī)定經(jīng)常被跳過結(jié)果就是排查半天發(fā)現(xiàn)是位數(shù)問題白白浪費一個下午。網(wǎng)絡(luò)側(cè)先做最樸素的驗證別一上來就開程序。機臺側(cè)的 IP、子網(wǎng)掩碼、網(wǎng)關(guān)要和采集機在同一網(wǎng)段防火墻把采集程序放行。用 PowerShell 探端口比 telnet 穩(wěn)因為 Windows 默認經(jīng)常沒裝 telnet 客戶端。# 1. 先確認三層可達 Test-Connection -ComputerName 192.168.1.20 -Count 4 # 2. 再確認端口通5007 只是常見默認值務(wù)必以機臺側(cè)設(shè)定為準 Test-NetConnection -ComputerName 192.168.1.20 -Port 5007 -InformationLevel Detailed # 3. 看本機是不是有多張網(wǎng)卡搶路由 Get-NetIPConfiguration | Where-Object { $_.IPv4DefaultGateway -ne $null }第二步返回TcpTestSucceeded : True才算通。如果 ping 通但端口不通八成是機臺側(cè)沒開對應(yīng)服務(wù)、端口號填錯、或者中間有設(shè)備做了端口過濾。第三步容易被忽略采集機如果同時接了辦公網(wǎng)和車間網(wǎng)默認路由可能把發(fā)往機臺的包甩到辦公網(wǎng)卡上表現(xiàn)是偶爾能通、大部分超時這種間歇性故障最難查先把路由理清楚。3.2 會話建立與句柄生命周期管理會話這層的核心原則只有一條一個采集實例對應(yīng)一個會話句柄且句柄的生命周期必須由狀態(tài)機管不能散落在業(yè)務(wù)代碼里。我見過最典型的錯誤寫法是在每次讀取時new一個通信對象讀一百次就泄漏一百個句柄跑兩小時機臺側(cè)直接拒絕新連接。正確做法是把通道包成一個單例式的、帶重連能力的對象。public sealed class EzCncChannel : ICncChannel { private readonly string _host; private readonly int _port; private readonly object _gate new object(); private dynamic _session; // 廠商對象具體類型按引用庫版本改 private DateTime _lastOpenFail DateTime.MinValue; public bool IsOpen { get; private set; } public EzCncChannel(string host, int port) { _host host; _port port; } public void Open() { lock (_gate) { // 失敗退避連續(xù)失敗時不要立刻重試避免把機臺側(cè)連接池打滿 if (DateTime.UtcNow - _lastOpenFail TimeSpan.FromSeconds(5)) return; try { _session Activator.CreateInstance(Type.GetTypeFromProgID(EzSocketLib.EzSocket)); _session.Open(_host, _port, 3000); // 第三個參數(shù)是超時單位 ms IsOpen true; } catch (Exception ex) { _lastOpenFail DateTime.UtcNow; IsOpen false; Log.Warn($open failed host{_host} err{ex.Message}); } } } public void Dispose() { lock (_gate) { try { _session?.Close(); } catch { /* 關(guān)閉失敗不拋避免拖垮退出流程 */ } _session null; IsOpen false; } } }這段代碼有三處值得說。_gate鎖保證同一時刻只有一個線程在建會話多線程并發(fā)Open是句柄泄漏的頭號來源。_lastOpenFail做的是失敗退避間隔設(shè) 5 秒機臺側(cè)網(wǎng)絡(luò)斷開時如果每 100ms 重試一次一分鐘就是 600 次無效連接有些實現(xiàn)會直接把源 IP 拉黑。Open的第三個參數(shù)是超時3000ms 是個折中值設(shè)太短機臺忙的時候誤判為斷線設(shè)太長采集線程被阻塞整個周期被拖垮。dynamic加ProgID的寫法是為了讓你不用在編譯期綁定具體類型庫換一個版本的運行庫時改個字符串就行。代價是沒有編譯期檢查方法名拼錯要運行到才知道。所以我會在Open成功后立刻做一次探針讀取讀一個必然存在的字段比如軸數(shù)讀不到就認為這次會話是假的主動關(guān)掉重來。ICncChannel的注釋里寫了「一次讀全量」實現(xiàn)時要注意廠商接口通常不支持真正的批量那就把多次讀取壓縮在一次會話內(nèi)完成別在兩次讀取之間做任何 IO 或數(shù)據(jù)庫操作。采集線程的黃金法則是會話期間只做內(nèi)存操作出了會話再談落庫。3.3 采集循環(huán)軸坐標、主軸轉(zhuǎn)速與報警號采集循環(huán)要解決三個具體問題周期怎么定、值怎么判重、異常怎么不中斷。周期不是越短越好NC 側(cè)的坐標刷新本身有內(nèi)部節(jié)拍你 10ms 讀一次讀到的可能還是同一個值白白占帶寬。我的經(jīng)驗值是坐標和轉(zhuǎn)速 100ms 到 200ms報警和程序號 500msPLC 側(cè)的開關(guān)量 50ms 到 100ms。這個粒度對絕大多數(shù)加工過程分析夠用對真正的插補級分析不夠但那就不是數(shù)采該干的事了。判重同樣重要。一臺機臺一天產(chǎn)生幾十萬條記錄其中大部分坐標是重復(fù)的。可以只存變化點 每 N 秒的心跳點存儲量能降一個數(shù)量級。下面這個循環(huán)把采集、判重、異常隔離串在一起。public sealed class Collector { private readonly ICncChannel _ch; private readonly IBlockingSink _sink; private readonly int _intervalMs; private CncSnapshot _last; public async Task RunAsync(CancellationToken ct) { var sw new Stopwatch(); while (!ct.IsCancellationRequested) { sw.Restart(); try { if (!_ch.IsOpen) _ch.Open(); if (_ch.IsOpen) { var snap _ch.ReadSnapshot(); snap.TimestampUtc DateTime.UtcNow; // 判重坐標變化超過 0.001mm 或距上次落庫超過 5s 才寫 if (IsChanged(snap) || (snap.TimestampUtc - _last.TimestampUtc).TotalSeconds 5) { _sink.Put(snap); // 只入內(nèi)存隊列絕不在采集線程里寫庫 _last snap; } } } catch (Exception ex) { Log.Error($collect error machine{_last?.MachineId} err{ex.Message}); _ch.Dispose(); // 出錯先拆會話下一輪重建 } var wait _intervalMs - (int)sw.ElapsedMilliseconds; if (wait 0) await Task.Delay(wait, ct); } } private bool IsChanged(CncSnapshot cur) { if (_last null) return true; if (cur.AlarmNo ! _last.AlarmNo) return true; if (cur.ProgramNo ! _last.ProgramNo) return true; for (int i 0; i cur.AxisPositions.Length; i) if (Math.Abs(cur.AxisPositions[i] - _last.AxisPositions[i]) 0.001) return true; return false; } }Stopwatch配合減去已耗時再 Delay的寫法是為了讓周期穩(wěn)定在設(shè)定值附近而不是設(shè)定值 執(zhí)行耗時逐輪累積漂移。這一點在長時間運行里差別很大不修正的話設(shè)定 100ms 實際跑成 130ms一天的樣本量少 23%做節(jié)拍分析時數(shù)據(jù)對不上。catch里直接Dispose而不是只記日志是因為通信異常之后會話對象的狀態(tài)往往已經(jīng)不可信繼續(xù)用它會讀到臟數(shù)據(jù)。拆掉重建的成本是幾十毫秒比讀一整天假數(shù)據(jù)劃算。_sink.Put只做內(nèi)存入隊這個約束必須硬性守住。一旦有人在采集線程里寫了一次數(shù)據(jù)庫數(shù)據(jù)庫抖動就會傳導(dǎo)成采集超時進而觸發(fā)重連進而雪崩。落地的事放到第 4 章單獨講。設(shè)備型號、軸數(shù)、程序號格式這些信息不同機型和系統(tǒng)版本差異不小代碼里凡是硬編碼的地方都建議提成配置項。4. 讓數(shù)據(jù)真正落下來時間戳、緩沖隊列與斷線重連能讀到數(shù)只是半程另一半在讀到的數(shù)怎么不丟、不亂、不把數(shù)據(jù)庫壓死。這一章講三件事為什么采集頻率必須和入庫頻率解耦、環(huán)形緩沖怎么設(shè)計、斷線重連的狀態(tài)機怎么寫才不會抖動。4.1 采集頻率不能跟著數(shù)據(jù)庫走新手最常見的架構(gòu)是采一條、寫一條代碼短邏輯直觀在單機臺、低頻率下確實能跑。但它有三個致命傷第一數(shù)據(jù)庫的寫入延遲會直接疊加到采集周期上一次慢查詢就能讓采集周期從 100ms 變成 2 秒第二網(wǎng)絡(luò)抖動時采集線程阻塞在 IO 上機臺側(cè)數(shù)據(jù)在緩沖區(qū)里堆積恢復(fù)后一次性涌進來形成尖峰第三采集和存儲的責(zé)任混在一起后面想換存儲介質(zhì)時序庫、消息隊列、文件就得動采集代碼。解耦的做法是在中間加一層有界隊列。采集線程只負責(zé)Put獨立的落地線程按批Take兩邊頻率互不影響。隊列要有界滿了之后采取丟最舊或阻塞采集的策略我一般選丟最舊并計數(shù)——數(shù)采場景里最新的數(shù)據(jù)永遠比歷史數(shù)據(jù)重要而丟了多少條本身就是一個應(yīng)該被監(jiān)控的健康指標。public sealed class BoundedSnapshotQueue : IBlockingSink { private readonly BlockingCollectionCncSnapshot _queue; private long _dropped; public BoundedSnapshotQueue(int capacity 20000) { // 有界隊列容量按最長斷線時間 × 采集頻率 × 機臺數(shù)估算 _queue new BlockingCollectionCncSnapshot(capacity); } public void Put(CncSnapshot snap) { if (!_queue.TryAdd(snap)) { // 隊列滿丟最舊保證最新數(shù)據(jù)一定進得去 if (_queue.TryTake(out _)) Interlocked.Increment(ref _dropped); _queue.TryAdd(snap); } } public IEnumerableCncSnapshot TakeBatch(int max, int timeoutMs) { var batch new ListCncSnapshot(max); if (_queue.TryTake(out var first, timeoutMs)) batch.Add(first); while (batch.Count max _queue.TryTake(out var more)) batch.Add(more); return batch; } public long DroppedCount Interlocked.Read(ref _dropped); }容量 20000 不是拍腦袋按 20 臺機臺、每臺 10 條/秒、允許 100 秒的數(shù)據(jù)庫不可用來估算正好兩萬。這個數(shù)應(yīng)該寫進配置而不是常量。TakeBatch先帶超時取第一條再非阻塞地把剩下的撈干凈這樣既不會空轉(zhuǎn)燒 CPU又能在有數(shù)據(jù)時一次取滿減少數(shù)據(jù)庫往返次數(shù)。DroppedCount暴露出來給監(jiān)控用這個值一旦持續(xù)增長說明落地側(cè)跟不上該加索引或者換存儲了。4.2 批量落庫與表結(jié)構(gòu)批量寫入的關(guān)鍵是批次大小和事務(wù)粒度的平衡。批次太小數(shù)據(jù)庫往返次數(shù)多批次太大一次失敗重放代價高而且長事務(wù)會鎖表。我一般取 500 到 2000 條一批配合SqlBulkCopy或者多值INSERT單批耗時控制在 200ms 以內(nèi)。表結(jié)構(gòu)上有個小設(shè)計能省很多事把變化點和心跳點用同一個表存加一個is_heartbeat標記。做過程分析時過濾掉心跳點做設(shè)備在線率統(tǒng)計時只看心跳點一張表兩用。CREATE TABLE cnc_snapshot ( id BIGINT IDENTITY(1,1) PRIMARY KEY, machine_id VARCHAR(32) NOT NULL, ts_utc DATETIME2(3) NOT NULL, -- 統(tǒng)一存 UTC展示層再轉(zhuǎn) axis_json NVARCHAR(512) NULL, -- 軸坐標數(shù)組序列化后存 spindle_speed DECIMAL(10,2) NULL, feed_rate DECIMAL(10,2) NULL, program_no INT NULL, alarm_no INT NULL, run_state TINYINT NULL, is_heartbeat BIT NOT NULL DEFAULT 0 ); -- 查詢模式基本固定為某臺機某段時間復(fù)合索引按這個建 CREATE INDEX ix_snapshot_machine_ts ON cnc_snapshot (machine_id, ts_utc) INCLUDE (alarm_no, run_state);ts_utc用DATETIME2(3)而不是DATETIME毫秒精度對判重和節(jié)拍分析是必要的DATETIME的 3.33ms 精度在 100ms 周期下會產(chǎn)生肉眼可見的對齊誤差。索引把alarm_no和run_state放進 INCLUDE是因為報表查詢幾乎總要帶上這兩個字段覆蓋索引能避免回表。axis_json這招在小規(guī)模場景下很好用省掉一張軸明細表。但如果后面要做任意軸的任意時間段曲線就得拆成cnc_axis_value(machine_id, ts_utc, axis_no, value)的窄表。這個改造越晚做代價越大如果一開始就知道要做軸級分析直接上窄表。4.3 斷線重連的狀態(tài)機重連邏輯寫不好會出現(xiàn)抖動放大網(wǎng)絡(luò)短暫抖動 1 秒程序瘋狂重連 100 次每次都失敗機臺側(cè)認為是攻擊行為。正確做法是用一個顯式狀態(tài)機把失敗次數(shù)變成退避時間的輸入。public enum LinkState { Disconnected, Connecting, Online, Degraded } public sealed class LinkStateMachine { private int _failCount; private DateTime _nextRetryUtc DateTime.MinValue; public LinkState State { get; private set; } LinkState.Disconnected; // 返回 true 表示本次允許嘗試連接 public bool ShouldTryConnect(DateTime nowUtc) { if (State LinkState.Online) return false; return nowUtc _nextRetryUtc; } public void OnSuccess() { _failCount 0; _nextRetryUtc DateTime.MinValue; State LinkState.Online; } public void OnFailure(DateTime nowUtc) { _failCount; // 指數(shù)退避1s, 2s, 4s, 8s ... 上限 60s var delaySec Math.Min(60, Math.Pow(2, Math.Min(_failCount - 1, 6))); _nextRetryUtc nowUtc.AddSeconds(delaySec); // 連續(xù)失敗 3 次以上進入 Degraded只告警不放棄 State _failCount 3 ? LinkState.Degraded : LinkState.Disconnected; } }退避上限設(shè) 60 秒是權(quán)衡的結(jié)果設(shè)太小起不到保護作用設(shè)太大比如 10 分鐘會讓一次短暫的網(wǎng)絡(luò)閃斷變成長時間的數(shù)據(jù)缺口。Degraded這個狀態(tài)很多人不設(shè)全用Disconnected表示結(jié)果就是剛斷 1 秒和斷了半小時在監(jiān)控上看起來一樣運維沒法判斷優(yōu)先級。狀態(tài)機的調(diào)用點必須在采集循環(huán)內(nèi)部而不是搞一個獨立的定時器去探活兩套節(jié)奏容易打架。采集循環(huán)每輪先問ShouldTryConnect返回 true 才真正去Open這樣重連節(jié)奏和采集節(jié)奏天然同步。5. 避坑與排查五個把我按在機臺旁邊的現(xiàn)場問題這一章的每一條都是真實踩過的按現(xiàn)象 → 原因 → 解決寫方便你對著癥狀查。5.1 連得上、讀得到但坐標全是 0現(xiàn)象會話建立成功Open沒報錯讀取也返回了對象但所有軸坐標都是 0主軸轉(zhuǎn)速也是 0唯獨報警號能讀到。原因多數(shù)是讀錯了數(shù)據(jù)區(qū)。NC 側(cè)的坐標分機械坐標、絕對坐標、相對坐標、剩余量等多個區(qū)有些實現(xiàn)需要顯式指定區(qū)號或者先切換到某個坐標系才返回有效值。另一個可能是軸號映射錯了讀的是不存在的軸實現(xiàn)層默默返回 0 而不是報錯。解決先用機臺的操作面板對照一次——把面板上顯示的機械坐標抄下來再和程序讀到的值逐個比對能立刻判斷是區(qū)錯了還是軸號錯了。代碼里加一個斷言如果所有軸同時為 0 且運行狀態(tài)為運行中視為異常打警告日志別讓它靜默寫庫。5.2 采集跑幾小時內(nèi)存漲到幾個 G現(xiàn)象程序啟動時內(nèi)存 80MB跑 8 小時后漲到 3GB最終 OOM 退出重啟后又慢慢漲。原因九成是隊列無界或者落庫線程因為異常退出了但沒人發(fā)現(xiàn)采集端一直往里塞。剩下的一成是 COM 對象沒釋放——每次讀取都new一個對象GC 又回收不了 COM 引用形成泄漏。解決隊列強制有界第 4 章那個實現(xiàn)落地線程用try/catch包住整個循環(huán)體出錯后延遲重啟而不是直接退出同時把隊列長度和落地線程是否存活打點到監(jiān)控。COM 對象嚴格按一個采集實例一個會話管理Dispose里顯式Close并置 null。上線前跑一次 24 小時浸泡用任務(wù)管理器看內(nèi)存曲線平穩(wěn)才算過。5.3 多機臺并發(fā)時隨機幾臺讀不到現(xiàn)象單臺調(diào)試一切正常一上到 10 臺并發(fā)總有 2 到 3 臺隨機超時重啟程序又能好一陣。原因線程數(shù)開太多每臺機臺一個線程加上定時器和日志線程池被占滿或者所有機臺共用同一個通信組件實例內(nèi)部鎖競爭導(dǎo)致排隊。還有一種隱蔽情況是采集機的網(wǎng)卡或交換機端口在突發(fā)并發(fā)下丟包。解決機臺數(shù)超過 8 臺時改用少量線程 異步輪詢的模型不要一臺一線程。通信組件按機臺實例化絕不共享。先把并發(fā)降到 3 臺看是否穩(wěn)定再逐步加找出臨界點。網(wǎng)絡(luò)側(cè)用ping -t長時間跑看有沒有規(guī)律性的丟包。5.4 報警號能讀到文本對不上現(xiàn)象alarm_no讀到 1024但程序里查表得到的文本和機臺面板顯示的完全不是一回事。原因報警文本不是 NC 標準數(shù)據(jù)的一部分它來自機臺廠商或者最終用戶自定義的報警表不同項目、不同系統(tǒng)版本差別很大。指望一套硬編碼的映射表通吃所有機臺必然翻車。解決把報警文本做成外部可配置的映射表按machine_model system_version alarm_no三鍵查找查不到就顯示原始編號并記錄一條未映射報警日志。跑一段時間后把這些未映射的編號導(dǎo)出來交給機臺側(cè)確認逐步補全。這樣即使映射不全數(shù)據(jù)也不會錯只是文本暫時缺失。5.5 時間戳差 8 小時報表全錯位現(xiàn)象數(shù)據(jù)庫里的時間和機臺面板顯示的時間差了整整 8 小時跨天統(tǒng)計全部錯位。原因采集機、數(shù)據(jù)庫、機臺三方的時區(qū)設(shè)置不一致有的存本地時間有的存 UTC匯總時又按本地時間截斷。解決全鏈路統(tǒng)一存 UTC只在展示層轉(zhuǎn)本地時區(qū)。機臺側(cè)如果只能提供本地時間采集時立刻轉(zhuǎn)成 UTC 并記錄原始時區(qū)偏移。數(shù)據(jù)庫字段名明確寫ts_utc讓后來的人沒有歧義空間。這一條改起來最便宜但漏掉的代價最大——時區(qū)錯了所有基于時間的分析全部作廢而且很難發(fā)現(xiàn)。6. 從 Demo 到產(chǎn)線用 72 小時浸泡和一張健康度表把穩(wěn)定性釘死Demo 能跑通和能上線之間隔著一段叫長時間穩(wěn)定性的距離。我的做法很笨但有效任何一套采集程序不管多簡單上線前必須跑滿 72 小時浸泡測試期間人為制造三次網(wǎng)絡(luò)中斷拔網(wǎng)線 30 秒、兩次機臺斷電重啟、一次數(shù)據(jù)庫重啟。測試期間只做一件事——盯著健康度指標看曲線不看日志里的成功字樣。健康度我只看五個指標多一個都是負擔指標采集方式合格線異常時的第一反應(yīng)采集周期偏差每輪記錄實際耗時算 P95P95 設(shè)定值 × 1.5查線程池和 GC 停頓隊列積壓深度定時采樣隊列長度穩(wěn)態(tài) 容量 20%查落地線程是否卡在慢 SQL丟棄條數(shù)隊列的 DroppedCount 增量24 小時為 0同上優(yōu)先擴批次而非擴容量重連次數(shù)狀態(tài)機 OnFailure 計數(shù)24 小時 3 次查網(wǎng)絡(luò)和機臺側(cè)連接數(shù)上限數(shù)據(jù)缺口時長相鄰兩條記錄的最大間隔 3 倍采集周期對照機臺運行狀態(tài)排除正常停機這五個指標里我最看重數(shù)據(jù)缺口時長因為它是一個結(jié)果性指標前四個出問題最終都會體現(xiàn)在它身上。實現(xiàn)上很簡單落地時記錄上一條記錄的時間戳超過閾值就打一條告警帶上機臺號和缺口時長。浸泡測試還有一個小技巧不要只測正常生產(chǎn)要專門測邊界。讓機臺在程序運行中途急停、在換刀時斷電、在報警狀態(tài)下保持兩小時。這些場景下讀出來的字段才是真正考驗解析邏輯的地方——正常加工時所有字段都有值邊界狀態(tài)下才會暴露某個字段其實一直返回緩存值這種問題。// 缺口檢測落地線程里順手做不需要額外定時器 private DateTime _lastTsUtc DateTime.MinValue; private void CheckGap(CncSnapshot snap, int intervalMs) { if (_lastTsUtc ! DateTime.MinValue) { var gapMs (snap.TimestampUtc - _lastTsUtc).TotalMilliseconds; // 閾值取 3 倍采集周期超過就告警但正常停機也會觸發(fā)需結(jié)合 run_state 判斷 if (gapMs intervalMs * 3) { Log.Warn($gap machine{snap.MachineId} gapMs{gapMs:F0} state{snap.RunState}); } } _lastTsUtc snap.TimestampUtc; }這段代碼的閾值取 3 倍周期是因為單次 GC 或者一次慢查詢造成 1 到 2 個周期的抖動是正常的追著這個告警會被淹沒。帶RunState一起打日志是為了區(qū)分真丟數(shù)據(jù)和機臺正常停機——后者在夜班和午休時段大量出現(xiàn)不區(qū)分的話告警沒有可讀性。還有一件事值得在 Demo 基礎(chǔ)上補把配置外置。機臺列表、IP、端口、采集周期、隊列容量、告警閾值全部從配置文件讀改一次參數(shù)不用重新編譯。我在一個模擬項目里就是因為把端口寫死在代碼里換機臺時不得不重新發(fā)布凌晨兩點在車間里抱著筆記本編譯那種體驗一次就夠了。從那以后我每次接數(shù)采項目第一件事就是把配置文件骨架立起來哪怕只有三臺機臺也不例外。希望幫到你。本文還有配套的精品資源點擊獲取