簡介面向C#開發(fā)者與工業(yè)自動化方向?qū)W習(xí)者的OPC DA客戶端示例工程圍繞OPCDAAuto.dll演示在.NET環(huán)境下訪問OPC服務(wù)器數(shù)據(jù)的實(shí)現(xiàn)方式適合需要了解COM組件調(diào)用、客戶端界面與基礎(chǔ)數(shù)據(jù)讀寫流程的中級讀者參考。壓縮包共58個文件、約223KB包含C#源碼、sln與csproj工程文件、OPCDAAuto.dll等組件、bat注冊腳本、exe與pdb運(yùn)行/調(diào)試產(chǎn)物以及config、resx、resources等配置和界面資源并附txt說明便于按工程結(jié)構(gòu)梳理各模塊職責(zé)。已有526人學(xué)習(xí)。工程內(nèi)保留主窗體、程序入口和項(xiàng)目配置等核心內(nèi)容可作為搭建私有OPC客戶端、排查COM引用與.NET框架兼容問題的對照樣例也方便在既有代碼上做二次開發(fā)和功能驗(yàn)證。1. 一線采集現(xiàn)場C# 寫 OPC Client為什么繞不開 OPCDAAuto.dll上個月接手一個改造項(xiàng)目現(xiàn)場一臺跑了七八年的 OPC DA 服務(wù)器組態(tài)軟件升級后對外只留一個 ProgID產(chǎn)線 MES 要把三百多個點(diǎn)位按秒級采上來。用 C# 寫 OPC Client最省事的路徑不是去啃 C 那套 COM 頭文件而是拿 OPCDAAuto.dll 這個自動化包裝把 OPCServer、OPCGroup、OPCItem 三個對象拼起來就能跑。這份資源就是圍繞它做的一套可運(yùn)行客戶端連服務(wù)器、瀏覽地址空間、批量同步讀寫、異步 DataChange 訂閱再配上斷線重連和點(diǎn)位配置。適合做上位機(jī)、采集網(wǎng)關(guān)、MES 接口的 C# 開發(fā)者前提是你得接受它底層仍然是 COM/DCOM注冊、位數(shù)、權(quán)限這幾關(guān)一個都繞不開。2. 環(huán)境準(zhǔn)備與組件注冊讓 OPCDAAuto.dll 在 C# 里 new 得出來2.1 目標(biāo)框架、平臺位數(shù)與引用方式的取舍先說最容易翻車的地方位數(shù)。OPCDAAuto.dll 是 COM 組件有 32 位和 64 位兩個版本市面上大量 OPC 服務(wù)器的自動化包裝只隨 32 位發(fā)布。C# 項(xiàng)目如果保持默認(rèn)的 AnyCPU在 64 位系統(tǒng)上會以 64 位進(jìn)程啟動去加載 32 位 COM 組件結(jié)果就是一句REGDB_E_CLASSNOTREG你查半天注冊表也查不出所以然。血淚經(jīng)驗(yàn)是采集端工程直接把平臺目標(biāo)鎖死為 x86別偷懶。哪怕機(jī)器是 64 位32 位進(jìn)程照樣能訪問遠(yuǎn)程 OPC 服務(wù)器性能損失在毫秒級采集場景下可以忽略?？蚣苓x .NET Framework 4.6 到 4.8 之間任意一版都可以。別一上來就用 .NET 6/8雖然新版對 COM 有ComWrappers之類的支持但默認(rèn)不開、坑更多而且現(xiàn)場工控機(jī)裝運(yùn)行時也麻煩。真要在新框架里跑常見做法是單獨(dú)起一個 x86 的 .NET Framework 采集子進(jìn)程通過管道或本地 socket 把數(shù)據(jù)吐給主程序用架構(gòu)隔離掉位數(shù)問題這比在新框架里硬折騰 COM 互操作靠譜。引用方式兩種我一般選第一種方式做法優(yōu)點(diǎn)代價COM 引用右鍵引用 → COM → 勾選 OPC DA Automation Wrapper 2.0生成強(qiáng)類型Interop.OPCAutomation.dll事件能直接部署時多帶一個 interop 程序集后期綁定Type.GetTypeFromProgID(OPC.Automation.2)dynamic不用帶 interopdynamic綁不了事件訂閱要寫反射很別扭很多人圖省事用dynamic結(jié)果做到異步訂閱那一步卡住——dynamic不支持事件訂閱語法只能GetType().GetEvent(DataChange).AddEventHandler(...)寫起來又臭又長。所以只要項(xiàng)目涉及 DataChange 回調(diào)就走 COM 引用。引用加完記得把 interop 程序集的「嵌入互操作類型」設(shè)為 False否則某些環(huán)境下事件接口會解析失敗。2.2 注冊 OPCDAAuto.dll 并驗(yàn)證 ProgID 是否可用把 dll 放到一個固定目錄比如C:\OPC\Bin\OPCDAAuto.dll然后用管理員權(quán)限的命令行注冊。64 位系統(tǒng)上有兩個 regsvr32選錯等于沒注冊:: 注冊 32 位組件最常用必須用 SysWOW64 下的 regsvr32 C:\Windows\SysWOW64\regsvr32.exe C:\OPC\Bin\OPCDAAuto.dll :: 如果你拿到的確實(shí)是 64 位版本才用 System32 下的 C:\Windows\System32\regsvr32.exe C:\OPC\Bin\OPCDAAuto.dll注冊成功會彈一個對話框。靜默注冊加/s參數(shù)適合打包進(jìn)安裝腳本。注冊完別急著寫業(yè)務(wù)代碼先驗(yàn)證 ProgID 到底能不能解析using System; class Program { static void Main() { // OPC DA 自動化包裝的固定 ProgID2.0 版本就是 OPC.Automation.2 Type t Type.GetTypeFromProgID(OPC.Automation.2); if (t null) { Console.WriteLine(ProgID 解析失敗組件未注冊或當(dāng)前進(jìn)程位數(shù)不對); return; } Console.WriteLine(CLSID t.GUID); } }這段代碼只有一件事確認(rèn)當(dāng)前進(jìn)程能不能看見這個 COM 類。Type.GetTypeFromProgID返回 null 就說明注冊表里沒有這個 ProgID或者你所在的進(jìn)程位數(shù)和組件不匹配——同一臺機(jī)器上 64 位進(jìn)程查不到 32 位組件注冊的類是常態(tài)不是異常。想再確認(rèn)一層打開注冊表看HKEY_CLASSES_ROOT\OPC.Automation.2\CLSID下面有沒有值有值再順著 CLSID 去看InprocServer32指向的 dll 路徑對不對。這三步走完環(huán)境問題基本就鎖定了一半。2.3 工程里的第一次握手連上本機(jī) OPC 服務(wù)器環(huán)境通了寫第一個連接。OPCServer.Connect兩個參數(shù)第一個是目標(biāo) OPC 服務(wù)器的 ProgID第二個是節(jié)點(diǎn)名傳空字符串表示本機(jī)using OPCAutomation; using System; class Program { static void Main() { OPCServer server new OPCServer(); try { // 第一個參數(shù)換成現(xiàn)場 OPC 服務(wù)器的真實(shí) ProgID第二個參數(shù)留空表示本機(jī) server.Connect(SomeVendor.OPCServer.1, ); Console.WriteLine($已連接{server.ServerName}); Console.WriteLine($版本{server.MajorVersion}.{server.MinorVersion}); Console.WriteLine($狀態(tài){server.ServerState}); // 1運(yùn)行 2失敗 3無配置 4掛起 5已加載 Console.WriteLine($啟動時間{server.StartTime}); } catch (System.Runtime.InteropServices.COMException ex) { // 常見 HRESULT0x80040154 類未注冊0x800706BA RPC 服務(wù)器不可用0x80070005 拒絕訪問 Console.WriteLine($連接失敗 0x{ex.ErrorCode:X8}{ex.Message}); } finally { if (server.ServerState 1) { server.Disconnect(); } } } }ServerState這個屬性很多人不看其實(shí)它是后面做重連狀態(tài)機(jī)的基礎(chǔ)返回 1 才代表服務(wù)器處于運(yùn)行態(tài)其他值該等就等、該重連就重連。異常處理里那三個 HRESULT 值得背下來0x80040154是本地注冊問題0x800706BA是網(wǎng)絡(luò)或目標(biāo)機(jī)器沒起來0x80070005是 DCOM 權(quán)限問題。分清這三個排查時間能省一大半。順帶說一句退出時的釋放。Disconnect()之后最好補(bǔ)一次Marshal.ReleaseComObject(server)雖然 .NET 有 GC但 COM 對象的引用計數(shù)不歸 GC 管程序頻繁啟停又沒釋放干凈現(xiàn)場會碰到「已達(dá)到最大連接數(shù)」這種玄學(xué)報錯。這個習(xí)慣后面每一章都得保持。3. 地址空間瀏覽與點(diǎn)位建模把服務(wù)器里的 Tag 拉成一張能維護(hù)的表3.1 用 BrowseOPCItemIDs 遞歸走一遍地址空間樹OPC DA 服務(wù)器的地址空間是一棵樹層級由廠商自己定常見的是「通道 → 設(shè)備 → 點(diǎn)位」三層也有扁平的。BrowseOPCItemIDs一次只返回一層所以要遞歸。關(guān)鍵參數(shù)是第一個決定你拿回來的是分支還是葉子using OPCAutomation; using System; using System.Collections.Generic; class Browser { // 遞歸收集所有葉子節(jié)點(diǎn)真正能讀寫的點(diǎn)位 ItemID static void Walk(OPCServer server, string parentId, Liststring leaves, int depth) { if (depth 6) return; // 防御性深度限制防止某些服務(wù)器返回環(huán)狀結(jié)構(gòu) Array children server.BrowseOPCItemIDs( (short)OPCBrowseFilter.OPCBranch, // OPCBranch分支 OPCLeaf葉子 OPCFlat扁平 parentId, // 從哪個節(jié)點(diǎn)往下瀏覽空字符串表示根 , // 過濾條件空表示不過濾 (short)VarEnum.VT_EMPTY, // 數(shù)據(jù)類型過濾VT_EMPTY 表示全部 (short)OPCAccessRights.OPC_READABLE // 只看可讀的 ); foreach (object id in children) { string itemId id.ToString(); // 每個分支本身也可能直接是一個點(diǎn)位所以兩邊都要瀏覽 Walk(server, itemId, leaves, depth 1); leaves.Add(itemId); } Array leafs server.BrowseOPCItemIDs( (short)OPCBrowseFilter.OPCLeaf, parentId, , (short)VarEnum.VT_EMPTY, (short)OPCAccessRights.OPC_READABLE); foreach (object id in leafs) leaves.Add(id.ToString()); } }OPCBrowseFilter三個枚舉值要分清楚OPCBranch只返回子分支OPCLeaf只返回能讀寫的葉子OPCFlat會一次性把子分支和葉子混著返回。新手容易直接用OPCFlat在層級深的服務(wù)器上會漏掉下層的點(diǎn)所以穩(wěn)妥寫法是分支和葉子分開遞歸。VarEnum.VT_EMPTY那個參數(shù)是數(shù)據(jù)類型過濾傳空值表示不過濾等你明確只要 Float 類型時再改。這套遞歸在幾百點(diǎn)的服務(wù)器上跑一次大概幾秒在幾千點(diǎn)的服務(wù)器上可能要十幾秒甚至更久。所以別把瀏覽寫進(jìn)每次啟動流程做成一個獨(dú)立的「點(diǎn)位導(dǎo)入」工具跑一次把結(jié)果存成 JSON 或 XML運(yùn)行時只讀配置。3.2 分通道/設(shè)備/點(diǎn)位建模型落成配置文件瀏覽出來的ItemID通常是Channel1.Device1.Tag001這種帶點(diǎn)分隔的長字符串直接拿它當(dāng)業(yè)務(wù)主鍵很難維護(hù)。我一般再做一層映射配置里寫清楚業(yè)務(wù)名、OPC 點(diǎn)位、數(shù)據(jù)類型、采集周期{ points: [ { code: TEMP_01, itemId: Channel1.Device1.Temperature, dataType: float, periodMs: 1000, writable: false }, { code: SPEED_SET, itemId: Channel1.Device1.SpeedSet, dataType: short, periodMs: 0, writable: true } ] }periodMs為 0 表示這個點(diǎn)不參與周期采集只在有寫操作時用。writable不是裝飾字段它對應(yīng)后面OPCItem.AccessRights的判斷寫之前先校驗(yàn)?zāi)苁〉粢慌€上誤操作。把瀏覽結(jié)果和這份配置做個比對缺哪個點(diǎn)、多哪個點(diǎn)一目了然比直接在代碼里零散硬編碼Channel1.Device1.Tag001強(qiáng)太多。3.3 點(diǎn)位可用性預(yù)檢先讀一次質(zhì)量碼再上線配置好了不代表點(diǎn)位真能讀。設(shè)備斷電、網(wǎng)關(guān)掉線、點(diǎn)位被組態(tài)軟件刪掉表現(xiàn)都是「能加到組里但質(zhì)量碼不對」。所以啟動階段要做一次預(yù)檢short quality; item.Read((short)OPCDataSource.OPCDevice, out object value, out quality, out object ts); // 質(zhì)量碼是一個位字段0xC0(192)Good0x40(64)Uncertain0x00Bad bool isGood (quality 0xC0) 0xC0; Console.WriteLine(${item.ItemID} value{value} quality0x{quality:X2} good{isGood});OPCDataSource.OPCDevice表示直接向設(shè)備要數(shù)據(jù)OPCCache表示讀服務(wù)器緩存。預(yù)檢必須用 Device不然緩存里是陳年舊值看著 Good 其實(shí)設(shè)備早斷了。質(zhì)量碼判斷別用 192這種硬比較它是位字段高兩位才是質(zhì)量等級用按位與更穩(wěn)。預(yù)檢結(jié)果打一份報告哪些點(diǎn) Good、哪些 Bad、哪些 Uncertain上線前先給現(xiàn)場確認(rèn)能避免后期扯皮。4. 組與項(xiàng)的讀寫同步、異步訂閱的完整鏈路4.1 OPCGroup 的三個關(guān)鍵參數(shù)UpdateRate、Deadband、IsSubscribedOPCGroup是 OPC DA 里最重要的抽象。服務(wù)器不是按點(diǎn)推送的是按組推送的一個組有統(tǒng)一的更新率和死區(qū)。所以點(diǎn)位的采集周期怎么分組直接決定服務(wù)器壓力OPCGroups groups server.OPCGroups; groups.DefaultGroupUpdateRate 1000; // 默認(rèn)組更新率單位毫秒 groups.DefaultGroupIsActive true; // 默認(rèn)組激活狀態(tài) groups.DefaultGroupDeadband 0; // 默認(rèn)死區(qū)0 表示數(shù)值不變也推送 groups.DefaultGroupIsSubscribed false; // 默認(rèn)不訂閱避免剛建組就狂推數(shù)據(jù) OPCGroup fastGroup groups.Add(FastGroup); // 參數(shù)是組名唯一即可 fastGroup.UpdateRate 200; // 200ms 刷一次 fastGroup.Deadband 0.5f; // 變化量小于 0.5 不推降負(fù)載 fastGroup.IsActive true; // 組是否向服務(wù)器要數(shù)據(jù) fastGroup.IsSubscribed true; // 是否觸發(fā) DataChange 回調(diào)UpdateRate是給服務(wù)器的建議值服務(wù)器可以不理你實(shí)際生效值看group.UpdateRate的回讀。Deadband是死區(qū)模擬量場景下很有用溫度從 25.0 變到 25.1 沒必要往上報設(shè)個 0.5 能砍掉大量無效回調(diào)。IsActive和IsSubscribed是兩個不同維度前者管服務(wù)器要不要刷新后者管客戶端要不要收回調(diào)。這兩個都設(shè) true 才會看到 DataChange只設(shè)一個的話表現(xiàn)就是「明明訂閱了卻沒反應(yīng)」這是新手最常踩的坑之一。分組策略上我一般按周期分層200ms 一組的快變量報警、聯(lián)鎖狀態(tài)1s 一組的過程量5s 一組的統(tǒng)計數(shù)據(jù)。別把所有點(diǎn)塞一個組服務(wù)器端一個組刷新要遍歷全部點(diǎn)位點(diǎn)多了會拖垮更新率。4.2 同步讀寫SyncRead/SyncWrite 的批量姿勢點(diǎn)加進(jìn)組之后同步讀寫是最好理解的部分。注意SyncRead/SyncWrite是組級接口走的是批量比逐點(diǎn)讀寫少很多次 COM 往返OPCItems items group.OPCItems; items.DefaultItemIsActive true; items.DefaultDataType (short)VarEnum.VT_EMPTY; OPCItem item1 items.AddItem(Channel1.Device1.Temperature, 1); // 第二個參數(shù)是 ClientHandle OPCItem item2 items.AddItem(Channel1.Device1.Pressure, 2); // 批量同步讀ServerHandles 用每個 item 的 ServerHandle Array serverHandles new object[] { item1.ServerHandle, item2.ServerHandle }; Array values, errors, qualities, timestamps; group.SyncRead( (short)OPCDataSource.OPCDevice, // 1緩存 2設(shè)備 serverHandles.Length, ref serverHandles, out values, out errors, out qualities, out timestamps); for (int i 1; i serverHandles.Length; i) // COM 返回的 SAFEARRAY 是 1-based { Console.WriteLine($值{values.GetValue(i)} 質(zhì)量0x{qualities.GetValue(i):X2} $錯誤{errors.GetValue(i)} 時間{timestamps.GetValue(i)}); }ClientHandle是客戶端自己分配的整數(shù)用來在回調(diào)里認(rèn)點(diǎn)。ServerHandle是服務(wù)器分配的讀寫批量接口用的都是它別搞混。這里最容易翻車的是數(shù)組下標(biāo)C# 里new object[]{...}是 0-based但 COM 回傳的SAFEARRAY是 1-based循環(huán)從 1 開始、用GetValue(i)取值直接values[0]會拋下標(biāo)異常。這個細(xì)節(jié)不寫注釋三個月后自己回來都看不懂。寫操作同理Array writeHandles new object[] { item2.ServerHandle }; Array writeValues new object[] { 12.5f }; Array writeErrors; group.SyncWrite(writeHandles.Length, ref writeHandles, ref writeValues, out writeErrors);寫的時候類型必須和點(diǎn)位定義的類型對得上寫 float 點(diǎn)位傳int會被服務(wù)器拒絕錯誤碼在writeErrors里不拋異常所以一定要檢查。SyncWrite只負(fù)責(zé)發(fā)送不保證設(shè)備側(cè)真的生效寫完再SyncRead一次Source 用 Device做寫后校驗(yàn)是工業(yè)現(xiàn)場比較穩(wěn)的做法。4.3 異步訂閱DataChange 回調(diào)為什么必須要有消息泵真正在生產(chǎn)里用的不是輪詢是訂閱。設(shè)好IsSubscribed true綁事件// 事件必須在組建立后、訂閱生效前綁定 group.DataChange new DIOPCGroupEvent_DataChangeEventHandler(OnDataChange); private static void OnDataChange(int transactionId, int numItems, ref Array clientHandles, ref Array itemValues, ref Array qualities, ref Array timeStamps) { for (int i 1; i numItems; i) // 仍然是 1-based { int handle Convert.ToInt32(clientHandles.GetValue(i)); object value itemValues.GetValue(i); short quality Convert.ToInt16(qualities.GetValue(i)); // handle 就是 AddItem 時傳入的 ClientHandle用它反查業(yè)務(wù)點(diǎn)位 } }回調(diào)是 COM 在 STA 線程上通過窗口消息觸發(fā)的這意味著控制臺程序里如果沒有消息泵事件永遠(yuǎn)不會進(jìn)來。現(xiàn)象是斷點(diǎn)打在OnDataChange上從來不命中而IsSubscribed明明是 true——不是訂閱沒生效是消息循環(huán)沒跑起來。解決辦法兩種要么宿主換成 WinForms/WPF主線程本身有消息循環(huán)要么在控制臺里顯式跑一個Application.Run(new ApplicationContext())或者定時Application.DoEvents()再或者把采集邏輯丟進(jìn)一個 STA 線程里跑消息循環(huán)。這是我在現(xiàn)場熬到凌晨兩點(diǎn)才定位到的問題值得單獨(dú)拎出來記。還有一個細(xì)節(jié)回調(diào)里的數(shù)組是復(fù)用的別把itemValues引用直接存進(jìn)隊列等別的線程處理要立刻把值拷貝出來否則下一批數(shù)據(jù)一來你手上的引用內(nèi)容就變了。4.4 寫值的類型轉(zhuǎn)換與寫后讀校驗(yàn)寫點(diǎn)位之前先看AccessRights1可讀、2可寫、3讀寫沒這個判斷直接寫遇到只讀點(diǎn)位就是一個 COM 異常還得自己 parse 錯誤信息。寫值的類型轉(zhuǎn)換我一般單獨(dú)封裝一層object ConvertToOpcType(object raw, short vt) { return vt switch { (short)VarEnum.VT_I2 Convert.ToInt16(raw), (short)VarEnum.VT_I4 Convert.ToInt32(raw), (short)VarEnum.VT_R4 Convert.ToSingle(raw), (short)VarEnum.VT_R8 Convert.ToDouble(raw), (short)VarEnum.VT_BOOL Convert.ToBoolean(raw), _ raw }; }vt從item.DataType拿轉(zhuǎn)換完再寫。不轉(zhuǎn)換直接傳double給VT_R4點(diǎn)位有些服務(wù)器會自己截斷有些直接返回錯誤碼行為不一致別賭。寫完做一次 Device 讀校驗(yàn)值對不上就記日志重試重試兩三次還不對就標(biāo)記點(diǎn)位異常交給上層報警不要在采集層死循環(huán)。5. 常見問題排查DCOM 玄學(xué)、位數(shù)不匹配、回調(diào)不通的那些坑5.1 現(xiàn)象new OPCServer()直接拋「檢索 COM 類工廠失敗錯誤 0x80040154」原因幾乎只有一個組件沒注冊或者注冊的位數(shù)和當(dāng)前進(jìn)程不匹配。32 位 dll 用 System32 下的 regsvr32 注冊表面提示成功其實(shí)注冊到了 64 位視圖32 位進(jìn)程仍然看不見。解決是按 2.2 節(jié)用 SysWOW64 下的 regsvr32 重注冊同時把 C# 工程的平臺目標(biāo)從 AnyCPU 改成 x86兩件事一起做才算徹底。5.2 現(xiàn)象本機(jī)連接正常換到另一臺機(jī)器連遠(yuǎn)程就報0x800706BA或0x80070005原因在 DCOM 這一層。遠(yuǎn)程調(diào)用要求兩臺機(jī)器的賬戶能互相認(rèn)證目標(biāo)機(jī)器的 DCOM 權(quán)限里沒有放行你的賬戶防火墻又沒開 135 端口和動態(tài)端口段。解決是打開dcomcnfg在組件服務(wù)里找到對應(yīng) OPC 服務(wù)器配「安全」選項(xiàng)卡的啟動和訪問權(quán)限加上你的賬戶「標(biāo)識」頁簽選「交互式用戶」或指定一個雙方都存在的本地賬戶防火墻臨時關(guān)掉做驗(yàn)證確認(rèn)是端口問題后再按最小范圍放開。遠(yuǎn)程跑通之后記得把臨時的寬松權(quán)限收回去。5.3 現(xiàn)象IsSubscribed true、事件也綁了OnDataChange一次都不觸發(fā)先在組和項(xiàng)上確認(rèn)IsActive、IsSubscribed都是 true再看宿主進(jìn)程有沒有消息泵?？刂婆_程序是最常見的翻車場景COM 的 STA 回調(diào)依賴窗口消息沒有消息循環(huán)事件隊列里堆著也不會派發(fā)。解決是換 WinForms 宿主或者在控制臺里跑一個 STA 線程加Application.Run。另外UpdateRate設(shè)得極小比如 1ms時有些服務(wù)器會直接忽略這個組回退到默認(rèn)值現(xiàn)象看起來也像「不推送」把更新率調(diào)回合理區(qū)間再試。5.4 現(xiàn)象讀到的值一直是舊的重啟程序才好大概率讀的是緩存。SyncRead的 Source 參數(shù)傳了OPCCache(1)或者OPCItem.Value屬性——這個屬性本身就是緩存值不會觸發(fā)設(shè)備刷新。解決是實(shí)時讀一律用OPCDevice(2)訂閱場景下等DataChange推上來。如果 Device 讀回來還是舊值那就是服務(wù)器到設(shè)備這一段斷了去看質(zhì)量碼通常是 Bad 或 Uncertain問題不在客戶端。5.5 現(xiàn)象程序退出后服務(wù)器側(cè)連接數(shù)沒釋放第二次啟動報連接數(shù)超限原因是 COM 對象和事件沒解綁。事件訂閱會讓服務(wù)器持有客戶端的回調(diào)引用不解綁就斷不干凈。退出順序固定成先group.DataChange - handler再server.OPCGroups.RemoveAll()然后server.Disconnect()最后Marshal.ReleaseComObject逐個釋放 group、items、server必要時補(bǔ)一次GC.Collect()加GC.WaitForPendingFinalizers()。把這套寫進(jìn)finally比事后救火強(qiáng)。6. 二次開發(fā)改造把 demo 級 Client 做成能長期跑的采集服務(wù)6.1 連接狀態(tài)機(jī)與斷線重連demo 里連上就完事生產(chǎn)里連接是個持續(xù)狀態(tài)。我的做法是用ServerState加定時器做心跳配一個簡單的狀態(tài)機(jī)Disconnected → Connecting → Connected → Degraded → Reconnecting。Degraded這個狀態(tài)很多人不加其實(shí)很有用——服務(wù)器還連著但部分質(zhì)量碼變 Bad 時不該直接重連先把壞點(diǎn)標(biāo)出來繼續(xù)采好點(diǎn)避免一次網(wǎng)絡(luò)抖動把整個采集鏈路打斷。重連要帶退避別一秒一次猛敲指數(shù)退避到 30 秒封頂穩(wěn)定后重置。6.2 點(diǎn)位配置化與采集調(diào)度點(diǎn)位從 3.2 節(jié)的 JSON 讀按periodMs分組每組建一個OPCGroup。采集結(jié)果先進(jìn)一個內(nèi)存環(huán)形隊列落庫和推 MQ 交給獨(dú)立的消費(fèi)者線程采集線程只管從 COM 拿數(shù)據(jù)絕不碰數(shù)據(jù)庫——COM 回調(diào)線程被慢 SQL 阻塞后面的數(shù)據(jù)全亂序這個坑踩過一次就記住了。寫操作單獨(dú)走一個命令隊列和采集線程分離避免寫請求把讀通道堵死。6.3 驗(yàn)證方法與改造邊界沒有現(xiàn)場設(shè)備時裝一個本地的 OPC DA 模擬服務(wù)器很多組態(tài)軟件自帶仿真驅(qū)動造幾百個點(diǎn)位跑壓力。驗(yàn)證指標(biāo)看三個DataChange的實(shí)際回調(diào)頻率是否接近UpdateRate、內(nèi)存是否隨運(yùn)行時長線性上漲漲就是事件沒解綁或數(shù)組沒拷貝、斷網(wǎng)恢復(fù)后多久回到 Connected 狀態(tài)。改代碼之前先在這套模擬環(huán)境里跑通別直接上現(xiàn)場試。最后說個教訓(xùn)。剛接觸 OPC DA 那會兒我把IsSubscribed設(shè)成 true 就以為萬事大吉結(jié)果在控制臺宿主里調(diào)了兩天一直以為是 DCOM 權(quán)限問題重裝組件、改注冊表、換機(jī)器全是無用功。從那以后我每次新建 OPC 采集工程第一件事就是寫個最小驗(yàn)證程序連上、加一個點(diǎn)、訂閱、打印回調(diào)五秒鐘能跑通再往上疊業(yè)務(wù)邏輯。這個習(xí)慣幫我省下的時間比任何調(diào)試技巧都多。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取