簡介OPC 客戶端開發(fā)中C# 與自動化接口的互操作常讓新手頭疼。這份源碼包正是面向這類場景包含 OPCAutomation.dll 與完整的 C# 工程源碼支持 S7200、S7300、S7400 等常見 PLC 的 OPC 通信開發(fā)既適合初學(xué)入門也可供有經(jīng)驗開發(fā)者直接參考。壓縮包內(nèi)共 32 個文件以 cs 源碼、exe 可執(zhí)行程序、resx/resources 資源文件為主并含 dll 互操作庫、pdb 調(diào)試符號、sln 解決方案等整體僅 171KB結(jié)構(gòu)輕量、便于快速部署。已有 871 人學(xué)習(xí)下載。讀者可從中獲得可運(yùn)行的 OPCClient 示例、互操作組件配置方法以及配套界面資源圖省去自己整合依賴與踩坑的時間直接在此框架上擴(kuò)展 S7200/300/400 的讀寫邏輯。1. 從MES要數(shù)據(jù)說起為什么還在用C#和OPCAutomation.dll做C#上位機(jī)的朋友基本都接過這樣的活產(chǎn)線上的PLC、傳感器、數(shù)控機(jī)床把運(yùn)行狀態(tài)數(shù)據(jù)送到某個老OPC服務(wù)器MES要從里面取數(shù)值業(yè)務(wù)方丟過來一臺裝了OPC Server的電腦就把整個采集工作扔給了你。Power Focus 6000扭矩值、設(shè)備電流、循環(huán)時間看著都是普通變量可對方補(bǔ)一句“不支持OPC UA只有DA”你就知道后面有得折騰了。OPCAutomation.dll是OPC基金會隨核心組件發(fā)布的自動化接口專門給VB/VBA/C#這類托管代碼調(diào)用OPC DA服務(wù)用的。它把OPCServer、OPCGroups、OPCGroup、OPCItems整套對象模型封裝成COM接口幾十行代碼能完成連服務(wù)器、加組、加項、讀、寫全流程。這篇筆記對應(yīng)一套可直接編譯的C#工程源碼加DLL跑通后替換ItemID就能接真實設(shè)備。適合剛?cè)胄械纳衔粰C(jī)新手也適合接項目要快速交付的熟手C#上位機(jī)面試前拿來過一遍COM互操作也很值。2. 環(huán)境搭起來32位RegAsm注冊與.NET COM引用2.1 先搞清楚OPCAutomation.dll在體系里的位置很多新人對OPCAutomation.dll有誤解以為裝上它就等于有了數(shù)據(jù)源。實際上它不是驅(qū)動它只是客戶端側(cè)的自動化包裝層。OPC DA體系里有兩類角色一類是OPC Server由設(shè)備廠商或組態(tài)軟件提供比如Kepware、西門子OPC軟件、Matrikon模擬器另一類是OPC客戶端也就是你寫的C#程序。OPCAutomation.dll屬于后者它把原生COM接口翻譯成容易調(diào)用的自動化接口讓C#可以用對象方式操作服務(wù)器但它自己不采集任何數(shù)據(jù)。選它而不是直接寫COM互操作原因很簡單效率。直接用IOleClientSite那套原生接口光連接、枚舉、處理IOPCItemMgt就要寫一大片樣板代碼而OPCAutomation把這一切收斂成了AddGroup、AddItem、SyncRead幾個方法。相比OPC UA它沒有證書、沒有安全策略配置缺點(diǎn)是依賴DCOM和Windows注冊表但這恰恰是存量設(shè)備的基本盤?，F(xiàn)在很多新項目用MODBUS、OPC UA協(xié)議讀取PLC和傳感器數(shù)據(jù)但老產(chǎn)線上已經(jīng)跑了好多年的DA服務(wù)器不會因為協(xié)議升級自動消失所以這套COM自動化接口仍然是上崗必修課。開發(fā)階段強(qiáng)烈建議先裝一個“免費(fèi)的OPC服務(wù)器”模擬器比如Matrikon OPC Simulation。它自帶幾十個模擬變量可以用來驗證客戶端邏輯避免直接在真實PLC上調(diào)試時把工藝變量寫壞。下表簡單列出整個依賴鏈條組件角色是否必需OPC Server提供變量空間與數(shù)據(jù)源是OPC Core Components含OpcEnum服務(wù)、OPCAutomation.dll是安裝Server時常會帶上OPCAutomation.dll自動化接口封裝供C#調(diào)用是DCOM/注冊表OPC DA通信與組件定位基礎(chǔ)是理解這個關(guān)系后后續(xù)所有環(huán)境問題都能歸類成兩類要么服務(wù)器沒起來要么客戶端找不到服務(wù)器或組件。2.2 項目里正確引用OPC Automation 2.0環(huán)境準(zhǔn)備的核心是把OPCAutomation.dll注冊到系統(tǒng)里然后在Visual Studio中完成COM引用。整個流程按下面順序走缺一步后面都會翻車。第一步在機(jī)器上安裝OPC Core Components。很多OPC Server安裝包會自帶也可以從OPC基金會官網(wǎng)單獨(dú)下載運(yùn)行庫。安裝完成后檢查系統(tǒng)目錄下是否存在OPCAutomation.dll注意32位版本通常出現(xiàn)在C:\Windows\SysWOW6464位版本出現(xiàn)在C:\Windows\System32。第二步用管理員身份打開命令提示符執(zhí)行32位RegAsm注冊。這里最容易被忽略的是必須用Framework目錄下的RegAsm不能用Framework64目錄下的cd C:\Windows\Microsoft.NET\Framework\v4.0.30319 regasm C:\Windows\SysWOW64\OPCAutomation.dll /codebase邏輯說明RegAsm會把程序集信息寫入注冊表/codebase讓系統(tǒng)從指定路徑加載DLL不依賴于全局程序集緩存。OPC DA的COM組件按32位注冊對應(yīng)注冊表節(jié)點(diǎn)是HKLM\SOFTWARE\WOW6432Node\Classes\CLSID所以必須用32位RegAsm。如果你在64位機(jī)器上用了Framework64目錄下的RegAsm注冊信息會寫入64位節(jié)點(diǎn)32位進(jìn)程照樣找不到。第三步Visual Studio中項目右鍵選擇“添加COM引用”類型庫列表里找到“OPC Automation 2.0”。如果機(jī)器上裝過多個OPC客戶端組件列表里可能出現(xiàn)多個版本優(yōu)先選2.0版。確定后把引用的“Embed Interop Types”屬性改為False。這個屬性如果保持默認(rèn)True運(yùn)行時CLR會動態(tài)生成互操作程序集碰到某些自定義OPC Server時類型庫不一致會拋異常改成False后所有COM類型由顯式互操作DLL決定行為穩(wěn)定得多。第四步把解決方案平臺目標(biāo)改為x86。這一步和代碼無關(guān)純粹是進(jìn)程位數(shù)問題。選中項目打開“生成”選項卡把“平臺目標(biāo)”從AnyCPU改成x86。原因在2.1說過OPC DA的COM組件基本都是32位64位進(jìn)程無法直接從32位注冊表加載它們。2.3 用一個診斷程序確認(rèn)注冊狀態(tài)環(huán)境配好了寫正式代碼前先花兩分鐘跑個診斷確認(rèn)COM組件能被CLR找到。這個診斷不用連服務(wù)器只檢查注冊表using System; class Program { static void Main() { Type t Type.GetTypeFromProgID(OPC.Server); if (t null) { Console.WriteLine(OPC.Server ProgID 未注冊請檢查 32 位 RegAsm 結(jié)果); } else { Console.WriteLine(已找到 COM 類型: t.FullName); } } }邏輯說明Type.GetTypeFromProgID只查注冊表不會真正實例化COM對象所以診斷過程是安全的。ProgID是COM類在注冊表中的文字標(biāo)識這里用通用的“OPC.Server”驗證自動化接口是否存在。參數(shù)說明如果你手里的服務(wù)器ProgID不是這個例如Kepware的ProgID是Kepware.OPC.KEPServerEX.V6直接把字符串換掉再跑一遍輸出FullName即代表注冊成功。如果輸出“未注冊”先回頭檢查2.2里的RegAsm路徑和平臺目標(biāo)。確認(rèn)注冊成功后再看下面章節(jié)的代碼模板。環(huán)境這關(guān)過了后面寫代碼基本不會遇到“類未注冊”這類問題。3. 連接與點(diǎn)位OPCServer、組、項的建立順序與ItemID確認(rèn)3.1 OPC DA的對象模型為什么非要有“組”O(jiān)PC DA客戶端編程核心是四級對象OPCServer、OPCGroups、OPCGroup、OPCItems/OPCItem。連接是OPCServer的事變量管理則通過組完成。給一個對象職責(zé)表對象職責(zé)關(guān)鍵成員OPCServer建立連接、斷開、瀏覽命名空間Connect、Disconnect、OPCGroupsOPCGroups組容器管理多個OPCGroupAdd、RemoveAll、DefaultGroupIsActiveOPCGroup項分組、讀寫、訂閱的載體SyncRead、SyncWrite、UpdateRate、IsActiveOPCItems組內(nèi)的項集合負(fù)責(zé)添加項AddItem、RemoveItem、RemoveAllOPCItem單個變量的句柄與值緩存ServerHandle、Value、Quality、TimeStamp為什么設(shè)計成“組”而不是直接操作變量因為OPC DA的讀、寫、訂閱都以組為粒度組內(nèi)共享刷新周期。一個組設(shè)置UpdateRate100ms組里所有項最快以100ms刷新另一個組要1s刷新一次就設(shè)1000ms。所以合理做法是把不同采集頻率的數(shù)據(jù)拆分到不同組而不是把所有變量塞到一個組里。這和使用習(xí)慣有關(guān)快變數(shù)值比如Power Focus 6000的實時扭矩單獨(dú)放一個高速組溫度、壓力這類慢變量放低速組。組內(nèi)項太多也會拖慢單次刷新幾百個點(diǎn)一個組在真實項目里響應(yīng)會明顯變慢。3.2 連接服務(wù)器并創(chuàng)建組的代碼模板下面是連接本機(jī)或遠(yuǎn)程OPC Server的典型代碼。這段代碼對應(yīng)工程源碼里的Connect部分可以直接復(fù)用using OPCAutomation; string host ; // 本機(jī)填空字符串遠(yuǎn)程填I(lǐng)P或計算機(jī)名 string progId Kepware.OPC.KEPServerEX.V6; // 改成實際服務(wù)器的ProgID Type serverType Type.GetTypeFromProgID(progId); if (serverType null) throw new Exception(未找到 ProgID: progId); OPCServer server (OPCServer)Activator.CreateInstance(serverType); server.Connect(host, progId); Console.WriteLine(連接成功: server.ServerName 狀態(tài) server.ServerState); OPCGroups groups server.OPCGroups; groups.DefaultGroupIsActive true; OPCGroup group groups.Add(ReadGroup); group.UpdateRate 100; group.IsActive true;邏輯說明COM類不能用new直接創(chuàng)建必須通過Type.GetTypeFromProgID拿到類型再Activator.CreateInstance實例化然后把對象強(qiáng)轉(zhuǎn)為OPCServer接口。Connect的第一個參數(shù)是主機(jī)名第二個是服務(wù)器ProgID本機(jī)連接時主機(jī)名留空。ServerState返回值對應(yīng)服務(wù)器運(yùn)行狀態(tài)通常2代表running0或1時服務(wù)器可能處于配置中或停止?fàn)顟B(tài)。參數(shù)說明UpdateRate單位是毫秒100表示100ms刷新一次。IsActive必須設(shè)為true否則后面AddItem的項不會參與數(shù)據(jù)刷新。注意groups.Add返回的OPCGroup不能丟后續(xù)所有讀寫都通過這個組對象進(jìn)行。3.3 添加項從ItemID到ServerHandle連接建立后下一步是向組里添加變量項。AddItem需要的核心參數(shù)是ItemID這是OPC Server命名空間里的唯一標(biāo)識object[] itemIDs new object[] { Channel1.Device1.Tag1, Channel1.Device1.Tag2 }; int[] clientHandles new int[] { 1, 2 }; Array serverHandles, errors; group.OPCItems.AddItem(itemIDs, clientHandles, out serverHandles, out errors); for (int i 0; i errors.Length; i) { int code (int)errors.GetValue(i); if (code 0) Console.WriteLine(添加成功服務(wù)器句柄: serverHandles.GetValue(i)); else Console.WriteLine(添加失敗錯誤碼: 0x code.ToString(X8)); }邏輯說明AddItem接收的是一個ItemID數(shù)組和一個客戶端句柄數(shù)組。ItemID是服務(wù)器命名空間里的字符串地址ClientHandle是你自己定義的整數(shù)用來在回調(diào)或批量讀取時識別“這個值屬于哪個變量”。服務(wù)器返回的ServerHandles數(shù)組才是后續(xù)讀寫的憑證必須保存好。參數(shù)說明itemIDs數(shù)組里字符串的格式完全取決于服務(wù)器。Kepware通常是“通道.設(shè)備.標(biāo)記”模擬器是“Random.Int1”、“Bucket Brigade.Int4”這種。AddItem返回的errors數(shù)組長度和itemIDs一一對應(yīng)0表示成功非0是一個HRESULT錯誤碼用ToString(X8)打印十六進(jìn)制方便查錯。這里有一個真實項目里高頻出現(xiàn)的問題手邊沒有點(diǎn)位表怎么確認(rèn)ItemID我一般按三個順序找。第一個在服務(wù)器所在機(jī)器上打開OPC客戶端工具比如Kepware自帶客戶端瀏覽整個命名空間樹把需要的節(jié)點(diǎn)路徑完整復(fù)制出來。第二個用模擬器先驗證程序邏輯把ItemID替換成模擬變量確認(rèn)讀寫代碼沒毛病后再換真實點(diǎn)位。第三個直接問設(shè)備供應(yīng)商要導(dǎo)出文件很多服務(wù)器支持導(dǎo)出CSV或UMM格式的點(diǎn)位表。Power Focus 6000這類扭矩控制器ItemID常見形如“PowerFocus6000.Channel_1.Torque”但也見過極簡命名“Atten.Dev1.Meas1”靠猜是最容易翻車的。4. 讀寫實戰(zhàn)同步Read/Write的代碼模板與HRESULT錯誤碼4.1 讀單個變量Value、Quality、TimeStamp一個都不能少同步讀是最穩(wěn)妥的采集方式調(diào)用一次ReadItem拿到值、質(zhì)量、時間戳三個結(jié)果。質(zhì)量位最重要很多人只看Value不管Quality結(jié)果把壞值當(dāng)成正常數(shù)據(jù)送進(jìn)MES這是現(xiàn)場最常見的“臟數(shù)據(jù)”來源object rawValue null; short quality 0; object timeStamp null; int serverHandle (int)serverHandles.GetValue(0); group.ReadItem(serverHandle, out rawValue, out quality, out timeStamp); Console.WriteLine(值{0}, 質(zhì)量{1}, 時間{2}, rawValue, quality, timeStamp); if (quality 192) { // 192 OPC_QUALITY_GOOD數(shù)據(jù)可靠 if (rawValue is float f) Console.WriteLine(讀取結(jié)果: {0:F1}, f); else if (rawValue is double d) Console.WriteLine(讀取結(jié)果: {0:F1}, d); }邏輯說明ReadItem是按服務(wù)器句柄讀單點(diǎn)執(zhí)行一次就是一次COM調(diào)用。quality字段是Int16192是OPC DA的Good質(zhì)量64表示Bad0通常代表無通信。質(zhì)量不為Good時即使Value有數(shù)值也不能用比如PLC停機(jī)瞬間讀到的保持值。參數(shù)說明timeStamp是COM的DATE類型封送過來的打印出來可能帶毫秒偏差用于數(shù)據(jù)追溯還行。rawValue是所有VARIANT類型的統(tǒng)一出口具體類型由服務(wù)器變量類型決定可能是float、double、int甚至bool所以后續(xù)轉(zhuǎn)換必須用類型判斷不能直接強(qiáng)轉(zhuǎn)。對于Power Focus 6000扭矩值這類數(shù)據(jù)如果服務(wù)器配置成單精度浮點(diǎn)rawValue通常就是float。4.2 寫單個變量類型不匹配是最大的坑寫入比讀取更敏感因為把錯誤值寫到設(shè)備可能造成工藝問題。OpcGroup的SyncWrite方法接收句柄數(shù)組和值數(shù)組代碼模板如下object writeHandle new object[] { serverHandles.GetValue(0) }; object writeVal new object[] { 25.0f }; // 按目標(biāo)變量類型構(gòu)造 object writeErr; group.SyncWrite(1, ref writeHandle, ref writeVal, out writeErr); int errCode ((Array)writeErr).GetValue(0) is int e ? e : 0; if (errCode ! 0) Console.WriteLine(寫入失敗: 0x errCode.ToString(X8)); else Console.WriteLine(寫入成功);邏輯說明SyncWrite的第一個參數(shù)是寫入點(diǎn)數(shù)這里固定為1。第二個和第三個參數(shù)是服務(wù)器句柄數(shù)組和寫入值數(shù)組必須一一對應(yīng)。順序錯了會把數(shù)值寫到另一個變量上這種錯位在批量寫入時很難察覺。參數(shù)說明值數(shù)組里的元素類型要和服務(wù)器變量類型匹配。服務(wù)器變量是浮點(diǎn)就傳float是整型就傳int。我的習(xí)慣是寫之前先讀一次原始值用讀到的rawValue類型作為構(gòu)造寫入值的依據(jù)讀出來是int就寫int讀出來是float就寫float。模擬器里的Random.Int1寫成float大概率返回錯誤因為服務(wù)器明確要求整型數(shù)據(jù)。4.3 HRESULT錯誤碼排查表OPC DA所有操作返回的都是HRESULTCOM層錯誤碼范圍在0x80040000到0x80042000之間。下表是現(xiàn)場出鏡率最高的幾個錯誤碼十六進(jìn)制習(xí)慣叫法含義與處理方向0x80040154CLASS_E_CLASSNOTAVAILABLE類未注冊。檢查32位RegAsm、平臺目標(biāo)x860x80070005E_ACCESSDENIEDDCOM權(quán)限拒絕。檢查Windows組件服務(wù)的訪問權(quán)限列表0x80040302OPC_E_UNKNOWNITEMIDItemID不存在。確認(rèn)命名空間別猜0x80040304OPC_E_INVALIDHANDLE句柄無效。服務(wù)器重啟后需要重新AddItem0x80010108RPC_E_DISCONNECTED連接斷開。檢查網(wǎng)絡(luò)、服務(wù)器進(jìn)程狀態(tài)遇到錯誤碼的第一反應(yīng)是把它轉(zhuǎn)成十六進(jìn)制字符串而不是看負(fù)數(shù)的十進(jìn)制。例如錯誤碼顯示-2147221246轉(zhuǎn)成十六進(jìn)制就是0x80040302查表立刻知道是ItemID問題。把這個習(xí)慣固化下來排障速度能快一個量級。5. 避坑專題OPCAutomation最容易翻車的五個運(yùn)行坑5.1 0x80040154類未注冊進(jìn)程位數(shù)惹的禍現(xiàn)象代碼編譯完全正常一執(zhí)行到Activator.CreateInstance就拋異?！癛etrieving the COM class factory for component with CLSID {xxx} failed due to the following error: 80040154”。原因OPCAutomation.dll按32位注冊到了WOW6432Node注冊表節(jié)點(diǎn)而程序卻以x64或AnyCPU方式運(yùn)行CLR去64位注冊表節(jié)點(diǎn)找CLSID自然找不到。還有一種情況是注冊時誤用了C:\Windows\Microsoft.NET\Framework64目錄下的RegAsm注冊信息寫到了64位節(jié)點(diǎn)。解決項目屬性里把平臺目標(biāo)改成x86重新生成。注冊時確保用Framework目錄不是Framework64目錄。改完后可以用reg query確認(rèn)CLSID確實存在于32位節(jié)點(diǎn)reg query HKLM\SOFTWARE\WOW6432Node\Classes\CLSID /s /f OPC.Automation /d這是個血淚經(jīng)驗生產(chǎn)機(jī)器上不要反復(fù)用不同版本RegAsm注冊同一個DLL注冊信息容易串到時候報錯就分不清是版本問題還是位數(shù)問題。我一般固定一個腳本把Framework路徑寫死每次部署都跑同一個腳本。5.2 AddItem返回0x80040302點(diǎn)位明明存在為什么找不到現(xiàn)象同一個服務(wù)器的客戶端工具里能看到點(diǎn)位復(fù)制了名字填進(jìn)去AddItem卻返回OPC_E_UNKNOWNITEMID。原因ItemID寫錯。最常見的錯法是拿顯示名稱當(dāng)ItemID比如Excel表里寫“設(shè)備1-溫度”實際ItemID是Device1.Tag1。還有分隔符問題Kepware用點(diǎn)號而不是斜杠Power Focus 6000的通道名可能帶下劃線?？崭窈鸵栆矔爝M(jìn)字符串肉眼很難發(fā)現(xiàn)。解決不在代碼里猜命名規(guī)則。用服務(wù)器自帶客戶端瀏覽命名空間鼠標(biāo)點(diǎn)上變量后直接復(fù)制完整ItemID。開發(fā)階段先加兩個模擬器點(diǎn)位驗證流程模擬器點(diǎn)位命名規(guī)則是公開的比如“Random.Int1”確認(rèn)代碼鏈路沒問題再切真實點(diǎn)位。真實項目中我遇到過客戶堅持說點(diǎn)位叫“AI-101”最后導(dǎo)出的點(diǎn)位表里實際是“AI_101”一個下劃線之差查了半天。5.3 Value類型錯亂為什么讀到的是System.Object[]現(xiàn)象ReadItem返回后把rawValue強(qiáng)轉(zhuǎn)成float拋出InvalidCastExceptionDebug一看類型值是System.Object[]。原因COM的VARIANT封送成.NET類型時不同版本的OPCAutomation.dll行為不完全一致。有些包裝器把單值變量封送成float有些封送成object[]如果服務(wù)器變量本身是數(shù)組類型還會出現(xiàn)二維數(shù)組。程序啟動時根據(jù)配置文件猜測類型最不靠譜服務(wù)器連接后變量類型才真正確定。解決讀取值后先做類型分支判斷不要用強(qiáng)轉(zhuǎn)。參考下面的寫法object v rawValue; if (v is float f) HandleFloat(f); else if (v is double d) HandleDouble(d); else if (v is Array arr arr.Length 0) { // 服務(wù)器返回的可能是數(shù)組取第一個元素分析 object first arr.GetValue(0); } else LogWarning(未識別的類型: v.GetType().FullName);這樣寫雖然代碼多了幾行但避免了運(yùn)行時崩潰。上位機(jī)程序跑在產(chǎn)線上一旦崩了影響的不只是數(shù)據(jù)采集可能連帶看板、報表全停。從那以后我所有OPC讀取代碼都強(qiáng)制走這個分支寧可多加兩個else不要賭服務(wù)器類型。5.4 IsSubscribedtrueDataChange卻一直不觸發(fā)現(xiàn)象組設(shè)置了IsActive和IsSubscribed事件代碼也掛了但程序運(yùn)行后回調(diào)一次都不執(zhí)行。更詭異的是WinForms界面卡死換成控制臺程序反而正常。原因OPCAutomation的異步回調(diào)依賴Windows消息泵。WinForms界面如果主線程被死循環(huán)占用消息泵不轉(zhuǎn)COM事件就派發(fā)不過來控制臺程序如果不主動運(yùn)行消息循環(huán)同樣等不到回調(diào)。還有部分OPC服務(wù)器對異步通知支持不完整需要服務(wù)器端的訂閱配置配合。解決把異步當(dāng)作備胎主流程用定時器同步讀。WinForms里直接用Timer控件OnTick里呼叫ReadItem循環(huán)控制臺程序用System.Timers.Timer回調(diào)里做同步讀加質(zhì)量判斷。這些場景對采集頻率要求沒那么高同步讀完全夠用。真正需要異步的是點(diǎn)位上千且要求毫秒級變化通知的SCADA場景那時候要在程序里顯式啟動消息泵復(fù)雜度會高不少一般上位機(jī)用不到。5.5 OpcEnum服務(wù)沒啟動遠(yuǎn)程服務(wù)器列表一片空白現(xiàn)象本機(jī)連接正常但遠(yuǎn)程主機(jī)提示找不到服務(wù)器甚至服務(wù)器列表是空的。有時候打開OPC客戶端工具能看到目標(biāo)服務(wù)器但自己寫的C#程序連不上。原因OPC DA發(fā)現(xiàn)遠(yuǎn)程服務(wù)器依賴OpcEnum服務(wù)在目標(biāo)機(jī)上進(jìn)行COM枚舉。Windows精簡版系統(tǒng)可能禁用了這個服務(wù)防火墻也會攔DCOM的135端口導(dǎo)致枚舉請求超時。解決在目標(biāo)服務(wù)器上以管理員身份打開services.msc找到“OPCEnum”服務(wù)啟動并把啟動類型改為自動。防火墻里放行OpcEnum程序同時允許遠(yuǎn)程DCOM訪問TCP 135端口放行。如果現(xiàn)場網(wǎng)絡(luò)策略不允許改防火墻就退而求其次Connect時填主機(jī)名而不是依賴服務(wù)器列表能繞過一部分枚舉依賴但DCOM權(quán)限仍然要配好否則后面訪問變量時會報0x80070005。6. 批量采集與釋放一個適合上位機(jī)的定時讀習(xí)慣6.1 用循環(huán)讀取代替逐條標(biāo)簽調(diào)用項目里幾十個點(diǎn)位是常態(tài)逐個寫ReadItem調(diào)用代碼會非常啰嗦。更常見的姿勢是保存好AddItem返回的serverHandles數(shù)組在定時器里統(tǒng)一循環(huán)int count serverHandles.Length; object[] snapshot new object[count]; short[] quality new short[count]; for (int i 0; i count; i) { object v null; short q 0; object ts null; group.ReadItem((int)serverHandles.GetValue(i), out v, out q, out ts); snapshot[i] v; quality[i] q; }這里的Count由ServerHandles數(shù)組長度決定。循環(huán)里每次ReadItem都做一次COM調(diào)用幾十個點(diǎn)還好上千點(diǎn)就要關(guān)注服務(wù)器負(fù)載。如果你的Interop版本里能看到返回多個結(jié)果的SyncRead重載優(yōu)先用那一種一次RPC調(diào)用取全組數(shù)據(jù)再拆數(shù)組性能差別很明顯沒有重載就用循環(huán)兜底工程上夠穩(wěn)定才是第一位的。6.2 資源釋放順序和重連后的句柄失效上位機(jī)程序一跑就是幾天甚至一個月句柄泄漏最容易在長期運(yùn)行中暴露出來。釋放順序必須是先停組再刪項最后斷開服務(wù)器group.IsActive false; group.OPCItems.RemoveAll(); groups.RemoveAll(); server.Disconnect(); Marshal.FinalReleaseComObject(server);還要記住一點(diǎn)AddItem返回的ServerHandle只在當(dāng)前服務(wù)器會話里有效服務(wù)器重啟后必須重新AddItem復(fù)用舊句柄會得到0x80040304。從那以后我每次接手C#上位機(jī)OPC項目都強(qiáng)制先跑一遍注冊表診斷、寫一個定時讀的驗證小程序確認(rèn)連接、讀值、質(zhì)量位都正常再開始加業(yè)務(wù)邏輯。這二十多分鐘的習(xí)慣能省掉后面一整天在點(diǎn)位表里猜ItemID的時間。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取