簡介需要快速搭建多相機(jī)OCR實(shí)時(shí)采集上位機(jī)的C#與Halcon開發(fā)者可直接使用這份完整工程代碼。解決方案圍繞四相機(jī)同步采集與OCR識(shí)別展開包含圖像獲取、窗口顯示及ROI區(qū)域生成等核心操作代碼中可見GetImageSize、SetPart、DispObj、GenRectangle1等Halcon算子調(diào)用便于理解聯(lián)合編程流程。壓縮包共100個(gè)文件約2.54MB主要包含C#工程源碼34個(gè).cs、編譯運(yùn)行所需的動(dòng)態(tài)庫14個(gè).dll、項(xiàng)目配置與資源文件resx、resources、config、xml等同時(shí)附有調(diào)試符號(hào)文件pdb和數(shù)據(jù)庫腳本sql工程結(jié)構(gòu)采用Models、DAL、TDDSE等多層劃分適合直接打開、修改與二次開發(fā)。已有1865人學(xué)習(xí)使用適合需要快速驗(yàn)證四相機(jī)OCR方案并完成上位機(jī)落地的相關(guān)技術(shù)人員。1. 4 個(gè)相機(jī)同時(shí) OCR 實(shí)時(shí)采集這套 C# 聯(lián)合 Halcon 的上位機(jī)方案解決什么問題一條產(chǎn)線上四個(gè)相機(jī)拍同一個(gè)工件的四個(gè)面或者拍四個(gè)工位每一幀都要把銘牌、序列號(hào)、批號(hào)這些字符實(shí)時(shí)讀出來交給上位機(jī)判定和存檔。這是 C# 聯(lián)合 Halcon 做多相機(jī) OCR 實(shí)時(shí)采集最典型的場景Halcon 負(fù)責(zé)取流、預(yù)處理和 OCR 識(shí)別C# 負(fù)責(zé)界面、線程調(diào)度、結(jié)果對(duì)齊和落庫兩邊各干各擅長的部分。標(biāo)題里那種可直接運(yùn)行的 Camare 壓縮包本質(zhì)上就是把這套流程封裝好拿到手改相機(jī) IP、改 ROI 就能跑。別對(duì)可直接運(yùn)行抱太高期待所謂直接跑前提是你的相機(jī)型號(hào)、Halcon 版本、.NET 平臺(tái)位數(shù)和作者當(dāng)時(shí)的環(huán)境一致否則第一步就會(huì)卡在 OpenFramegrabber 報(bào)錯(cuò)上。這套方案適合兩類人剛接手機(jī)器視覺上位機(jī)開發(fā)的 C# 工程師需要快速理解 Halcon 在 C# 里的調(diào)用模型和 4 路相機(jī)并行的基本框架以及已經(jīng)用 Halcon 做單相機(jī)檢測、準(zhǔn)備擴(kuò)展到多相機(jī)的視覺工程師想看看別人把線程、隊(duì)列、OCR 結(jié)果對(duì)齊做成什么樣。下面按「選型 → 最小代碼 → 并行框架 → 踩坑 → 調(diào)優(yōu)」往下講每段都可以照抄。2. 選型先于編碼Halcon 調(diào)用方式、4 路相機(jī)連接與 OCR 模型怎么定2.1 C# 調(diào)用 Halcon 的三種姿勢HDevEngine、導(dǎo)出代碼與 HALCON.NETC# 和 Halcon 協(xié)作常見做法有三種選錯(cuò)后面全在返工。第一種HDevEngine 方式。Halcon 腳本存成 .hdev 或 .hdvpC# 里用 HDevEngine 執(zhí)行。好處是算法改動(dòng)不用重新編譯 C# 工程視覺工程師改完腳本你直接生效壞處是變量來回傳遞麻煩每個(gè)圖像變量和設(shè)備句柄都要通過 SetInputIconicObject 塞進(jìn)去多相機(jī)場景里這種反復(fù)拷貝很浪費(fèi)而且調(diào)試時(shí)錯(cuò)誤棧隔了一層定位慢。我不建議在 4 路實(shí)時(shí)采集上用這種方式。第二種導(dǎo)出代碼方式。在 Halcon 的 HDevelop 里把寫好的腳本通過 File - Export 導(dǎo)出成 C# 文件得到一個(gè) HDevelopExport 類里面每個(gè)腳本步驟對(duì)應(yīng)一個(gè)方法。這是工業(yè)上位機(jī)里最常見的形態(tài)標(biāo)題里那個(gè)壓縮包大概率就是這種結(jié)構(gòu)。好處是算法邏輯所見即所得導(dǎo)出方法可以單獨(dú)調(diào)用壞處是代碼里有大量中間變量和 DispObj 調(diào)用需要手動(dòng)刪改不然 UI 線程會(huì)被 Halcon 窗口刷新拖死。第三種直接用 HALCON.NET 的 HOperatorSet 寫 C# 代碼完全不經(jīng)過腳本。適合我們這種對(duì)算子熟的工程師代碼最直接對(duì)象生命周期自己掌控多線程下最好排查問題。我自己的項(xiàng)目基本都是這種方式后面所有代碼也按這個(gè)風(fēng)格寫。無論選哪種都要引用 HalconDotNet.dll并且工程平臺(tái)目標(biāo)x64/x86和安裝的 Halcon 版本位數(shù)必須一致。32 位 Halcon 配 AnyCPU 編譯出來的程序經(jīng)常在開發(fā)機(jī)上好好的部署到現(xiàn)場就報(bào) BadImageFormatException 或者 Halcon 類型轉(zhuǎn)換錯(cuò)誤這類問題排查起來比寫代碼還耗時(shí)間。2.2 四路相機(jī)的連接規(guī)劃GigE 帶寬、巨型幀與觸發(fā)方式4 路相機(jī)接什么接口決定了你后面所有代碼怎么寫。工業(yè)現(xiàn)場最普遍的是 GigE Vision走網(wǎng)口線可以拉到 100 米而且 Halcon 的 GigEVision 接口最成熟。但千兆網(wǎng)的帶寬賬要先算清楚一臺(tái) 900 萬像素相機(jī)Bayer 8bit 單幀約 9MB跑到 30fps 就需要 270MB/s千兆網(wǎng)實(shí)際有效載荷只有 110MB/s 左右一臺(tái)相機(jī)就把一條網(wǎng)線吃滿了。所以 4 路 GigE 相機(jī)要么降低幀率、縮小 ROI要么上雙口網(wǎng)卡相機(jī) 1、2 走網(wǎng)卡 A相機(jī) 3、4 走網(wǎng)卡 B再配靜態(tài) IP 分流。巨型幀是個(gè)高頻坑。Halcon 的 GigEVision 采集默認(rèn)依賴 Jumbo Frame網(wǎng)卡、交換機(jī)、相機(jī)三方都得開 9000 字節(jié)缺一樣就會(huì)丟幀、抓圖超時(shí)表現(xiàn)是4 個(gè)相機(jī)只能打開 2 個(gè)。另外相機(jī) IP 要提前規(guī)劃Halcon 的 GigE 相機(jī)啟動(dòng)后往往不在 192.168.1.x 網(wǎng)段先拿廠商工具把 4 臺(tái)相機(jī) IP 改成同一網(wǎng)段的不同地址再讓 InfoFramegrabber 枚舉否則 OpenFramegrabber 連設(shè)備名都看不到。觸發(fā)方式也要在選型階段定。多相機(jī)實(shí)時(shí)采集有兩種走法軟觸發(fā)上位機(jī)發(fā)一個(gè)命令讓 4 臺(tái)相機(jī)同時(shí)曝光簡單但抖動(dòng)有幾十毫秒硬觸發(fā)PLC 給每臺(tái)相機(jī)的 Line0 接口同時(shí)發(fā)脈沖多臺(tái)相機(jī)曝光時(shí)刻嚴(yán)格同步。產(chǎn)線上有 PLC 的項(xiàng)目我一般會(huì)堅(jiān)持硬觸發(fā)否則第 4 章講到的結(jié)果對(duì)齊會(huì)讓你痛不欲生。還有一批廉價(jià) USB 相機(jī)走 DirectShow 或 UVC 接口回調(diào)里區(qū)分多攝像頭靠枚舉序號(hào)加序列號(hào)雙保險(xiǎn)但這種接口延遲高、幀率不穩(wěn)做 4 路 OCR 實(shí)時(shí)采集不推薦除非你對(duì)成本極度敏感。2.3 OCR 模型選型MLP 還是 CNN字符集不是越大越好Halcon 的 OCR 模型分兩類。傳統(tǒng) MLP 分類器ReadOcrClassMlp 加載工業(yè)場景最常用的是 Industrial_0-9A-Z_NoRej字符集覆蓋數(shù)字和大寫字母NoRej 表示不拒絕非字符區(qū)域適合噴碼、鋼印、激光打標(biāo)這種字符密度高的場景。新版 Halcon 還有 CNN 模型 ReadOcrClassCnnUniversal_0-9A-Z_NoRej 這類對(duì)復(fù)雜背景、字符變形、打印不清晰的魯棒性明顯更好代價(jià)是每幀推理多幾毫秒。四相機(jī)并行的場景里每幀多 3 毫秒會(huì)被放大成整體吞吐下降所以我一般這么選字符是標(biāo)準(zhǔn)印刷體、背景干凈、光源固定MLP 就夠字符有殘缺、背景有紋理、產(chǎn)品表面反光嚴(yán)重直接上 CNN 省得后面天天為識(shí)別率加班。Halcon 也提供基于深度學(xué)習(xí)的 OCR 方案需要自己采集樣本訓(xùn)練產(chǎn)線項(xiàng)目里除非上述兩種都試過且不達(dá)標(biāo)否則不建議一上來就上訓(xùn)練數(shù)據(jù)的量級(jí)和標(biāo)注成本遠(yuǎn)超你想象。字符集的選擇很多人會(huì)犯一個(gè)錯(cuò)以為越大越好。實(shí)際恰恰相反你只讀數(shù)字就選純數(shù)字庫混進(jìn)字母后 O 和 0、I 和 1、Z 和 2 這些相似字符會(huì)把置信度拉下來誤判率翻倍。先把現(xiàn)場字符范圍摸清楚再定庫這是 OCR 項(xiàng)目的第一步也是絕大多數(shù)識(shí)別率問題的根源。3. 最小可運(yùn)行代碼C# 打開 4 個(gè)相機(jī)并實(shí)時(shí)抓圖的完整流程3.1 枚舉相機(jī)與 OpenFramegrabber 參數(shù)逐個(gè)拆解先寫最小的打開邏輯。Halcon 在高版本里對(duì) GigE Vision 相機(jī)的枚舉方式是這樣using HalconDotNet; using System; HTuple info, values; HOperatorSet.InfoFramegrabber(GigEVision, device, out info, out values); for (int i 0; i values.Length; i) { Console.WriteLine($Device[{i}] {values[i].S}); }values 里返回的就是類似 CAMERA1、CAMERA2 這樣的設(shè)備名Halcon 按相機(jī) MAC 或序列號(hào)生成不是按插線順序。重插網(wǎng)線或者換相機(jī)后名字會(huì)變所以設(shè)備名到工位號(hào)的映射要寫進(jìn)配置文件不要寫死在代碼里。拿到設(shè)備名后逐個(gè)打開OpenFramegrabber 的參數(shù)順序一個(gè)都不能錯(cuò)public class HalconCamera { private HTuple _acqHandle; public string DeviceName { get; } public HalconCamera(string deviceName) { DeviceName deviceName; } public bool Open() { HOperatorSet.OpenFramegrabber( GigEVision, // 采集接口類型 0, 0, // 水平/垂直分辨率0 表示用相機(jī)默認(rèn) 0, 0, // 圖像寬度/高度0 表示默認(rèn) 0, 0, // 水平/垂直偏移 default, // 輸入格式像素格式 -1, // 外部觸發(fā)模式-1 不限制 default, // 相機(jī)像素格式 -1, // 線掃描寬度面陣相機(jī)傳 -1 false, // 是否使用相機(jī)自帶連接 DeviceName, // 設(shè)備名從 InfoFramegrabber 枚舉來 port, // 端口類型 0, // 端口號(hào) out _acqHandle); return _acqHandle ! null; } }這段代碼最容易抄錯(cuò)的就是前面那一串 0 和 default 的順序。OpenFramegrabber 是 Halcon 里參數(shù)最多的算子之一每個(gè)參數(shù)位置都對(duì)應(yīng)一個(gè)硬件特性你把寬度和高度寫反了不會(huì)報(bào)錯(cuò)出來的圖就是裁剪的。打開后先 GrabImage 試讀一幀能拿到圖再繼續(xù)往下寫別一口氣把 4 臺(tái)全開了再調(diào)。3.2 GrabImageAsync 異步抓圖與圖像隊(duì)列界面卡頓的解藥同步 GrabImage 在取流時(shí)會(huì)阻塞當(dāng)前線程4 臺(tái)相機(jī)如果一個(gè)線程輪流同步抓整體幀率被最慢的那臺(tái)拖死。常見做法是每臺(tái)相機(jī)一個(gè)采集線程循環(huán)調(diào) GrabImageAsyncusing System.Collections.Concurrent; using System.Threading; public class GrabWorker { private readonly HTuple _acqHandle; private readonly ConcurrentQueueHObject _queue new ConcurrentQueueHObject(); private volatile bool _running true; public GrabWorker(HTuple acqHandle) { _acqHandle acqHandle; } public void Loop() { while (_running) { HObject image; // timeout 設(shè)為 -1 表示無限等待200~500 更適合斷線檢測 HOperatorSet.GrabImageAsync(out image, _acqHandle, -1); _queue.Enqueue(image); // 隊(duì)列超過 5 幀說明消費(fèi)端處理不過來丟最舊幀防止內(nèi)存膨脹 while (_queue.Count 5 _queue.TryDequeue(out HObject drop)) { drop.Dispose(); } } } public void Stop() { _running false; } }GrabImageAsync 的第三個(gè)參數(shù)是超時(shí)毫秒數(shù)-1 表示一直等下一幀。這個(gè)參數(shù)很關(guān)鍵相機(jī)斷線時(shí) GrabImageAsync 會(huì)一直阻塞線程就掛死了所以我實(shí)際項(xiàng)目中會(huì)設(shè) 200 到 500 毫秒超時(shí)后做一次相機(jī)連接檢查再?zèng)Q定重新打開還是報(bào)警。隊(duì)列上限是背壓策略識(shí)別線程跟不上時(shí)寧可丟幀也不能讓內(nèi)存無限漲——HObject 是非托管資源一個(gè) 900 萬像素的 HObject 就是 9MB積壓 200 幀就是 1.8GB內(nèi)存爆掉只是時(shí)間問題。這里要特別強(qiáng)調(diào) HObject 必須手動(dòng) Dispose。C# 的 GC 管不到非托管內(nèi)存你光等 Finalize 讓 Halcon 自己回收吞吐一大內(nèi)存還是只增不減。隊(duì)列里每個(gè)對(duì)象要么被消費(fèi)線程釋放要么在丟幀邏輯里釋放沒有第三條路。3.3 OCR 識(shí)別調(diào)用鏈ReadOcrClassMlp 與 DoOcrMulti 的輸入輸出抓圖回路穩(wěn)定后接 OCR。初始化時(shí)把模型讀一次整條鏈路共用同一個(gè)句柄public class OcrEngine { private HTuple _ocrHandle; public void Load(string modelName) { // 初始化階段只調(diào)用一次不要在識(shí)別線程里反復(fù)讀文件 HOperatorSet.ReadOcrClassMlp(modelName, out _ocrHandle); } public string Recognize(HObject image) { HObject thresholdRegions, connectedRegions, selectedRegions; HTuple classes, confidences; try { // 字符區(qū)域分割閾值 連通域 形狀篩選 HOperatorSet.Threshold(image, out thresholdRegions, 0, 128); HOperatorSet.Connection(thresholdRegions, out connectedRegions); HOperatorSet.SelectShape(connectedRegions, out selectedRegions, height, and, 10, 200); // 多字符 OCR輸入候選區(qū)域和原圖輸出字符和置信度 HOperatorSet.DoOcrMulti(selectedRegions, image, _ocrHandle, out classes, out confidences); var sb new System.Text.StringBuilder(); for (int i 0; i classes.Length; i) { sb.Append(classes[i].S); // confidences[i].D 是 0~1 的置信度后面判定用 } return sb.ToString(); } finally { thresholdRegions?.Dispose(); connectedRegions?.Dispose(); selectedRegions?.Dispose(); } } }DoOcrMulti 輸出兩個(gè)數(shù)組classes 是識(shí)別出的字符confidences 是對(duì)應(yīng)的置信度。閾值 128 是拍腦袋值實(shí)際要按現(xiàn)場圖像灰度直方圖定后面第 6 章展開。這里最典型的錯(cuò)誤是每幀都調(diào)用 ReadOcrClassMlp模型文件加載一次要幾十毫秒4 臺(tái)相機(jī)一疊加幀率直接腰斬所以必須初始化時(shí)加載好所有線程共享同一個(gè)句柄。另外注意 DoOcrMulti 只接受單通道圖像相機(jī)出的是彩色圖先轉(zhuǎn)灰度ConvertImageType 或 ReductionDomain 都行直接喂彩色圖大概率報(bào)錯(cuò)。區(qū)域分割這里只用了最簡單的 Threshold 加 SelectShape真實(shí)場景還要考慮光照變化這塊放到第 6 章一起說。4. 四相機(jī)并行與結(jié)果匯總線程模型、時(shí)間戳對(duì)齊與 SQLite 落庫4.1 每相機(jī)一線程的三層架構(gòu)采集線程、識(shí)別線程、UI 線程4 路相機(jī)并行最穩(wěn)的結(jié)構(gòu)是每臺(tái)相機(jī)兩個(gè)后臺(tái)線程采集線程 識(shí)別線程加上一個(gè) UI 線程三層之間用 ConcurrentQueue 解耦。采集線程只負(fù)責(zé) GrabImageAsync 入隊(duì)識(shí)別線程從隊(duì)列取圖做 OCRUI 線程通過事件或者定時(shí)器批量刷新界面。任何 Halcon 算子都不允許在 UI 線程里跑這是鐵律。為什么采集和識(shí)別要拆兩個(gè)線程因?yàn)?OCR 算子再快也要幾毫秒如果同一個(gè)線程先抓圖再識(shí)別抓圖間隔就變成曝光、傳輸、識(shí)別三者的總和幀率上不去。拆開后采集線程永遠(yuǎn)在等下一幀識(shí)別線程只處理最新幀互不阻塞。識(shí)別線程里取隊(duì)列要用取最新幀邏輯private void OcrLoop(string ocrModel) { HTuple ocrHandle; HOperatorSet.ReadOcrClassMlp(ocrModel, out ocrHandle); // 只加載一次 while (_running) { if (_grabQueue.TryDequeue(out HObject latest)) { // 隊(duì)列里可能還積壓著舊幀全部丟掉只處理最新的 while (_grabQueue.TryDequeue(out HObject stale)) { stale.Dispose(); } var text _ocr.Recognize(latest); latest.Dispose(); // 觸發(fā)結(jié)果事件事件里只入隊(duì)不做 UI 刷新 OnFrameResult?.Invoke(new OcrResult(text, DateTime.Now, DeviceName)); } else { Thread.Sleep(5); } } }OnFrameResult 用 Action 委托或者自定義事件都行但事件處理器里絕對(duì)不能直接去 update UI、寫數(shù)據(jù)庫。識(shí)別線程一被阻塞隊(duì)列就漲上來丟幀率跟著上升。我一般讓事件處理器只做一件事把結(jié)果放進(jìn)另一個(gè) ConcurrentQueueUI 用一個(gè) 100ms 的 Timer 批量拉取刷新寫庫交給獨(dú)立線程。這樣界面再卡也不會(huì)拖垮識(shí)別。4.2 多相機(jī)結(jié)果對(duì)齊同一個(gè)工件四相機(jī)拼讀的三種策略如果 4 個(gè)相機(jī)拍的是同一個(gè)工件的不同面最終要把 4 路結(jié)果拼成一個(gè)完整記錄再判定。這里最坑的是同一幀的認(rèn)定光靠時(shí)間戳對(duì)齊是最省事但也最容易出錯(cuò)的做法。第一種時(shí)間戳對(duì)齊適合軟觸發(fā)場景。上位機(jī)同時(shí)給 4 臺(tái)相機(jī)發(fā)觸發(fā)命令抓到圖后打上 Environment.TickCount 或 Stopwatch 時(shí)間戳識(shí)別完把同一觸發(fā)周期內(nèi)的結(jié)果歸組。軟觸發(fā)本身有幾十毫秒抖動(dòng)工件走快了一個(gè)相機(jī)早拍了 50ms字符位置和樣貌已經(jīng)變了識(shí)別率不穩(wěn)。第二種 PLC 流水號(hào)對(duì)齊這是工業(yè)現(xiàn)場最靠譜的方案。每個(gè)工件過觸發(fā)傳感器時(shí)PLC 發(fā)一個(gè)流水號(hào)給上位機(jī)上位機(jī)把當(dāng)前收到的 4 路結(jié)果關(guān)聯(lián)到這個(gè)流水號(hào)上。相機(jī)漏拍或重拍時(shí)流水號(hào)能明確告訴你缺哪一路直接標(biāo)記 NG 等待復(fù)判。光靠時(shí)間戳遇到漏拍就全線錯(cuò)位后面所有數(shù)據(jù)都對(duì)不上這是血淚經(jīng)驗(yàn)。第三種圖像特征對(duì)齊用工件上本來存在的二維碼或關(guān)鍵字符做關(guān)聯(lián)。每個(gè)工位識(shí)別出同一枚唯一碼后按碼歸組適合產(chǎn)品自帶碼的場景但前提是每個(gè)拍攝面都能讀到同一個(gè)碼很多工位布局滿足不了。我現(xiàn)在的習(xí)慣是現(xiàn)場有 PLC 就一定接流水號(hào)沒有 PLC 才退而求其次用時(shí)間戳并且把時(shí)間戳容差設(shè)到 100ms 以上寧可多等一幀也別錯(cuò)配。4.3 結(jié)果落庫與異常重拍SQLite 記錄、超時(shí)與 NG 處理OCR 結(jié)果、原圖路徑、時(shí)間戳、工位號(hào)都要落庫。工業(yè)上位機(jī)最務(wù)實(shí)的選擇是 SQLite單文件、免安裝、部署零成本。每幀一條記錄字段大致是 id、timestamp、camera_id、ocr_text、confidence、image_path、is_ngprivate static readonly string ConnStr Data Sourceocr_results.db; public void SaveResult(OcrResult r) { using var conn new SQLiteConnection(ConnStr); conn.Open(); using var cmd conn.CreateCommand(); cmd.CommandText INSERT INTO ocr_log(timestamp, camera_id, ocr_text, confidence, image_path, is_ng) VALUES(ts, cam, text, conf, img, ng); cmd.Parameters.AddWithValue(ts, r.Timestamp); cmd.Parameters.AddWithValue(cam, r.CameraId); cmd.Parameters.AddWithValue(text, r.Text); cmd.Parameters.AddWithValue(conf, r.Confidence); cmd.Parameters.AddWithValue(img, r.ImagePath); cmd.Parameters.AddWithValue(ng, r.IsNg); cmd.ExecuteNonQuery(); }這里有個(gè)必踩的坑SQLite 寫庫有鎖4 個(gè)識(shí)別線程同時(shí)寫同一張表很快報(bào) database is locked。解決方式兩種一是給寫庫加全局鎖簡單但吞吐受限二是單寫線程 ConcurrentQueue 批量落庫寫庫線程每 200ms 把隊(duì)列里的結(jié)果攢成一個(gè)事務(wù)批量插入一次事務(wù)插幾十條效率高也不會(huì)鎖。超時(shí)重拍的邏輯要單獨(dú)設(shè)計(jì)。置信度低于閾值比如 0.8或者干脆沒讀到字符時(shí)先判斷是不是曝光、焦距問題重拍最多兩次重拍還 NG 就把原圖歸檔、標(biāo)記人工復(fù)判。不要無限制重拍產(chǎn)線節(jié)拍會(huì)被你堵死NG 圖保留下來反而是后面訓(xùn)練和調(diào)優(yōu)最值錢的資產(chǎn)。5. C# 聯(lián)合 Halcon 的 5 個(gè)高頻翻車現(xiàn)場現(xiàn)象、原因與解決辦法5.1 Access Violation C0000005對(duì)象的釋放順序現(xiàn)象程序運(yùn)行一段時(shí)間后或者關(guān)閉窗口時(shí)C# 拋出 System.AccessViolationException錯(cuò)誤碼 C0000005調(diào)用棧指向 HalconDotNet 的某個(gè)析構(gòu)函數(shù)或者 HOperatorSet 調(diào)用。原因HObject 和 HTuple 是非托管資源的包裝C# 的 GC 可能在你還用著圖像時(shí)觸發(fā)了終結(jié)器或者你在別的線程 Dispose 了正在使用的對(duì)象。最常見的場景一個(gè) HObject 進(jìn)了隊(duì)列兩個(gè)線程都持有引用消費(fèi)線程用完 Dispose采集線程還在往窗口畫這一幀一崩一個(gè)準(zhǔn)。解決跨線程傳遞的 HObject 所有權(quán)必須明確誰最后使用誰釋放。生產(chǎn)線程只負(fù)責(zé)入隊(duì)消費(fèi)線程負(fù)責(zé) Dispose中間不允許第三方觸碰。調(diào)試期可以在項(xiàng)目屬性里打開 GC 并發(fā)回收的開關(guān)來復(fù)現(xiàn)但這種問題要靠規(guī)范根治每個(gè)線程的局部 HObject 用 using 塊包裹回調(diào)到 UI 的 HObject 一定先深拷貝或者只傳句柄。這個(gè)報(bào)錯(cuò)很玄學(xué)不是每次都崩取決于 GC 時(shí)機(jī)現(xiàn)場復(fù)現(xiàn)極其痛苦。我現(xiàn)在寫多相機(jī)代碼第一步永遠(yuǎn)是畫清楚每個(gè) HObject 的流向圖誰生產(chǎn)、誰消費(fèi)、誰釋放畫不清楚不寫代碼。5.2 License 報(bào)錯(cuò)腳本跑得好好的一加線程就報(bào)無授權(quán)現(xiàn)象單線程調(diào)試時(shí) Halcon 算子全部正常把 GrabImageAsync 或者 DoOcrMulti 放進(jìn)后臺(tái)線程后報(bào) H9991 無可用授權(quán)或者 license 無效。原因Halcon 授權(quán)機(jī)制綁定到調(diào)用上下文試用授權(quán)只允許單線程執(zhí)行多線程并行跑算子會(huì)直接觸發(fā)授權(quán)校驗(yàn)失敗。另外 HDevEngine 和導(dǎo)出代碼的授權(quán)校驗(yàn)方式不同同一個(gè) license.dat 換個(gè)調(diào)用方式可能就不認(rèn)了。解決第一確認(rèn)用的是正式 Runtime 授權(quán)而不是試用授權(quán)正式授權(quán)支持多線程試用授權(quán)跑單線程是它的設(shè)計(jì)邊界不是 bug第二確認(rèn) C# 工程平臺(tái)目標(biāo)和 Halcon 位數(shù)一致位數(shù)不匹配經(jīng)常誘發(fā)奇怪的授權(quán)和類型錯(cuò)誤第三license.dat 的路徑要保證所有線程都能讀到別放在用戶臨時(shí)目錄或者相對(duì)路徑部署到 Windows 服務(wù)里路徑一變就授權(quán)失敗。還有個(gè)常見的連帶坑license 文件到期時(shí)間是半夜第二天早上產(chǎn)線一開機(jī)就報(bào)錯(cuò)。生產(chǎn)項(xiàng)目一定要在代碼里做授權(quán)剩余天數(shù)檢查提前三天在界面上告警別讓操作員大早上對(duì)著紅屏找你。5.3 4 個(gè)相機(jī)只能打開 2 個(gè)GigE 帶寬與驅(qū)動(dòng)配置現(xiàn)象OpenFramegrabber 打開前兩個(gè)相機(jī)正常第三個(gè)或第四個(gè)報(bào)無法連接、超時(shí)或者都打開成功了抓圖一多就開始丟幀、卡頓。原因網(wǎng)卡、交換機(jī)、相機(jī)三者沒同時(shí)開 Jumbo Frame巨型幀4 路相機(jī)在千兆網(wǎng)上的小包傳輸把帶寬和 CPU 中斷都打滿了。900 像素相機(jī)單幀 9MB不開巨型幀一個(gè)幀被拆成幾百個(gè)小包CPU 中斷風(fēng)暴一來網(wǎng)卡先崩。解決所有網(wǎng)絡(luò)設(shè)備包括相機(jī)都設(shè)置 Jumbo Frame 9000單路帶寬按 寬×高×位深×幀率 計(jì)算保留 30% 余量雙口網(wǎng)卡靜態(tài) IP 分流相機(jī) 1、2 走網(wǎng)卡 A相機(jī) 3、4 走網(wǎng)卡 B再把網(wǎng)卡中斷的 CPU 親和性分散到不同核心避免所有中斷擠在一個(gè)核上?，F(xiàn)場還有一個(gè)容易忽略的點(diǎn)相機(jī) IP 與上位機(jī)不在同一網(wǎng)段Halcon 枚舉時(shí)看得到設(shè)備但 OpenFramegrabber 就是連不上先用廠商工具改 IP 再上代碼。5.4 OCR 準(zhǔn)確率早晚差異大曝光與 ROI 沒固化現(xiàn)象同一套代碼白天識(shí)別率 99%傍晚太陽斜照進(jìn)車間誤識(shí)別率直線上升8 認(rèn)成 3O 認(rèn)成 0。原因環(huán)境光變化導(dǎo)致圖像整體灰度偏移你閾值分割寫死了 128早上字符灰度 150傍晚掉到 100分割出來的區(qū)域不是缺筆畫就是多粘連。Halcon 的 OCR 對(duì)光照變化比人眼敏感得多。解決光源固定是第一優(yōu)先能加遮光罩就加遮光罩能用頻閃光源就用頻閃光源把環(huán)境光的影響壓到最低相機(jī)曝光和增益鎖成固定值絕對(duì)不要開自動(dòng)曝光自動(dòng)曝光會(huì)讓字符灰度反復(fù)橫跳閾值不要寫死用灰度直方圖定位峰谷或者用 MedianImage 降噪后配合 dyn_threshold 做動(dòng)態(tài)分割。ROI 也一定要按基準(zhǔn)圖像標(biāo)定好不要每幀全圖找字ROI 固定后還能順手把光源邊緣的偽區(qū)域?yàn)V掉。5.5 關(guān)程序就崩潰句柄銷毀順序現(xiàn)象點(diǎn)關(guān)閉按鈕界面退了進(jìn)程還賴在任務(wù)管理器里或者退到一半崩潰主窗口關(guān)了但報(bào) Halcon 窗口無效。原因UI 線程關(guān)閉時(shí)銷毀了 HWindowControl但采集、識(shí)別線程還在向窗口推送圖像或者調(diào)用 disp_obj。Halcon 的窗口句柄一旦銷毀任何往這個(gè)窗口畫的算子都直接崩潰。解決退出順序必須是「停線程 → 釋句柄 → 關(guān)窗口」protected override void OnFormClosing(FormClosingEventArgs e) { _running false; // 1. 通知所有線程退出 _grabThread?.Join(1000); // 2. 等采集線程退出帶超時(shí) _ocrThread?.Join(1000); // 3. 等識(shí)別線程退出 _acqHandle?.Dispose(); // 4. 釋放相機(jī)句柄 _window?.Dispose(); // 5. 最后釋放 Halcon 窗口 base.OnFormClosing(e); }順序反了就是玄學(xué)崩潰先 Dispose 了相機(jī)句柄采集線程還在等圖線程內(nèi)部訪問已釋放句柄Access Violation。Join 一定要帶超時(shí)參數(shù)不然線程卡死在 GrabImageAsync 里窗體永遠(yuǎn)關(guān)不掉。這個(gè)退出流程我現(xiàn)在每個(gè)項(xiàng)目第一個(gè)寫寫完再動(dòng)其他代碼。6. 把 OCR 準(zhǔn)確率從 90% 提到 99%預(yù)處理順序、自定義訓(xùn)練與回歸驗(yàn)證6.1 預(yù)處理三板斧OCR 識(shí)別之前必須過三關(guān)順序不能反。第一關(guān)灰度化彩色圖 ConvertImageType 轉(zhuǎn)灰度Halcon 的 OCR 算子只吃單通道第二關(guān)去噪增強(qiáng)字符印在紋理背景上時(shí)先做高斯差分DoG把低頻背景濾掉再分割效果立竿見影普通工況用 MedianImage 或 GaussFilter 就夠第三關(guān)形態(tài)學(xué)清理開運(yùn)算去掉孤立鹽噪點(diǎn)閉運(yùn)算把斷掉的筆劃接上。之后再做閾值分割和字符候選提取。濾波核大小的經(jīng)驗(yàn)值按字符高度比例定取字符高度的十分之一到五分之一。字符高度 30 像素濾波核取 3 到 5太大字符糊掉太小不起作用。這個(gè)參數(shù)值得用驗(yàn)證集調(diào)多花半小時(shí)調(diào)濾波后面少加一個(gè)月班。6.2 自定義字符庫訓(xùn)練自帶庫實(shí)在扛不住時(shí)用 Halcon 的 OCR Training 工具自己訓(xùn)。流程是固定的抓一批現(xiàn)場圖像框出字符逐個(gè)標(biāo)注字符值生成 .trf 訓(xùn)練文件用 create_ocr_class_mlp 生成分類器最后 write_ocr_class_mlp 導(dǎo)出。C# 里不需要改一行代碼ReadOcrClassMlp 加載你導(dǎo)出的模型文件就行。訓(xùn)練集每類字符至少要 50 個(gè)樣本覆蓋不同光照、偏移、粗細(xì)、缺損程度。只標(biāo)幾張圖訓(xùn)出來的分類器實(shí)際就是記住了你那幾張圖換一幀就露餡。訓(xùn)完用驗(yàn)證集測準(zhǔn)確率達(dá)不到就回去補(bǔ)樣本這一步不能省。6.3 批量回歸驗(yàn)證改任何參數(shù)之前先建驗(yàn)證集。從現(xiàn)場歷史圖里挑 500 張好的壞的都要跑一個(gè)批處理腳本統(tǒng)計(jì)字符級(jí)準(zhǔn)確率和整串準(zhǔn)確率。整串準(zhǔn)確率才是產(chǎn)線真正關(guān)心的指標(biāo)因?yàn)榕卸ㄊ钦葘?duì)。某個(gè)字符識(shí)別率 99% 聽著不錯(cuò)但產(chǎn)品碼 12 位整串全對(duì)的概率是 0.99 的 12 次方87%這數(shù)據(jù)上不了線。我平時(shí)用一個(gè)簡單的控制臺(tái)命令做回歸輸入圖片目錄和期望識(shí)別結(jié)果輸出每張圖的識(shí)別文本和置信度跑完自動(dòng)和期望值對(duì)比打印整串通過率。每次改曝光、改預(yù)處理、換模型都把同一批圖跑一遍通過率不能比上一次低。這是我在現(xiàn)場唯一認(rèn)可的驗(yàn)收標(biāo)準(zhǔn)做不到 99% 整串通過率別急著交產(chǎn)線。這套多相機(jī) OCR 上位機(jī)的框架說到底就是「線程隔離 資源管理 數(shù)據(jù)對(duì)齊」三件事。我現(xiàn)在的習(xí)慣是接到項(xiàng)目先寫退出流程和對(duì)象流向圖再談識(shí)別率優(yōu)化。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取