简介这套C#与Halcon混合编程的机器视觉框架源码面向视觉检测与自动化设备开发者覆盖AOI视觉检测、机械手定位、点胶机、插件机、激光切割机、视觉螺丝机、贴合机、激光焊接机、视觉裁板机等典型场景可用于快速验证和落地视觉项目。压缩包共1427个文件以671个cs源码、185个resx资源文件、101个dll动态库为主辅以配置文件、图标、脚本和工程文件整体大小71.93MB工程结构完整在VS2019下可直接编译运行。框架采用插件式开发内置手眼标定模块支持相机静止与运动状态下的视觉定位并提供C#脚本扩展能力便于按需定制检测流程与算法逻辑同时涵盖模板匹配、测量、数据展示、发送数据等功能模块方便二次开发与功能组合。目前已有368人学习/下载适合希望快速搭建机器视觉应用、缩短项目开发周期的工程师参考。1. C#Halcon机器视觉框架源码它解决的从来不是编译看到“C#Halcon机器视觉框架源码到手vs2019可以直接编译”这个描述先别把它当成开箱即用的成品。VS2019能编译只是门票框架真正的价值在于把相机采集、Halcon算子、坐标标定、通信交互和配方管理拆成清晰的模块让一台点胶机、螺丝机、AOI检测设备、激光焊接机或裁板机在更换产品时只改配置和参数不重写算法代码。对于做自动化设备的软件工程师来说这套东西省掉的是“每个新项目都从零搭一遍”的重复劳动。新手也能把它当一条机器视觉学习路线先看模块边界再追算子调用最后自己加一个检测流程。下面我顺着这个标题把这个框架该有的样子、在vs2019里跑起来的步骤以及落地时最容易翻车的地方一条条讲清楚。2. 先把框架看透C#主控与Halcon算子引擎的职责分工2.1 为什么用Halcon而不是OpenCV从标定、匹配到测量的工程账很多工程师纠结过“halcon和opencv的区别”。OpenCV是开放算法库算子全、可控性强但模板匹配、亚像素边缘、手眼标定这些工程化能力需要自己拼装跨版本还容易遇到底层API变动。Halcon的优势不在单个算子而在于它把工业场景里最常用的形状匹配、Blob分析、测量、标定做成了闭环配合HDevelop可以现场拖拽调试、导出代码参数调起来比OpenCV直观很多。在C#里调用Halcon常见做法有两种。一种是直接引用官方提供的halcondotnet.dll通过HObject和HTuple在C#代码里操作另一种是用HDevEngine在C#中加载HDevelop脚本适合把“调参逻辑”留给现场。实际框架里固定流程的检测用第一种居多因为它不依赖脚本解释执行路径更直接出问题也容易用VS断点查。如果原来是从QT/C转来做C#的QT里调Halcon通常走C接口切到C#后核心思路是一样的都是把HObject当作图像数据的中枢区别只在界面线程和调度方式。从选型账上看自动化设备的上位机基本跑在Windows工控机上C#做界面、串口、TCP通信的生态非常顺手Halcon负责视觉部分也正好补足了C#在图像算法上的短板。这个组合是当前设备集成商里最常见的配置。2.2 框架里的五个模块边界相机、算法、标定、通信、配方一套能支撑多种设备的机器视觉框架源码目录通常长这样VisionFramework/ ├─ Cameras/ # 相机抽象层 │ ├─ IVisionCamera.cs # 相机接口 │ ├─ UvcCamera.cs # USB/UVC相机实现 │ └─ GigECamera.cs # 网口相机实现 ├─ Vision/ # Halcon算法封装层 │ ├─ ShapeModelJob.cs # 模板匹配 │ ├─ BlobJob.cs # 区域检测 │ └─ MeasureJob.cs # 测量类 ├─ Calibration/ # 标定模块 ├─ Comm/ # 串口/网口/Modbus通信 ├─ Recipe/ # 配方管理JSON配置 ├─ UI/ # WinForms/WPF界面 └─ App.cs # 启动入口这个目录结构的关键是相机层不依赖算法层算法层不关心相机品牌。设备换相机只需要实现同一个相机接口换检测逻辑只需要新增一个Vision下的Job类。模块边界清晰之后机械手定位、点胶机、AOI检测这些看起来不同的设备才能在同一个框架里共存。很多“到手编译不通过”的框架问题就出在模块之间互相耦合。相机回调里直接调算法、算法类里直接new一个Form、通信数据写死在视觉流程里一旦换设备就要动C#源码框架就失去意义了。所以看源码时先看边界不要急着追某个算子的实现。2.3 用IVisionJob把点胶机、螺丝机、焊接机统一成一套流程框架里最值得抄的接口是视觉流程的统一抽象。点胶机要定位Mark点、螺丝机要检测漏锁、焊接机要测焊缝位置本质上都是“取图 → 预处理 → 找特征 → 输出结果”。这个共性可以用一个接口表达public interface IVisionJob { string Name { get; } // 从配方文件加载本工序的检测参数 bool Load(string recipePath); // 执行视觉流程 VisionResult Execute(HObject image); } public class VisionResult { public bool IsOk { get; set; } public double Row { get; set; } public double Column { get; set; } public double Angle { get; set; } public double Score { get; set; } public long ElapsedMs { get; set; } }Load负责把阈值、匹配分数、ROI位置从JSON里读进来Execute只接收HObject图像返回坐标和判断结果。这样上层UI、通信模块只依赖接口不需要知道具体是哪个检测算法。框架给点胶机做定位和给螺丝机做漏锁检测差的就是一个Job实现和一份配方文件。这个接口的设计逻辑是把“算法”变成“可替换的零件”。设备切换时不用重新编译整个上位机只替换对应Job类或者直接改JSON里的检测项。后面第4章会展开讲怎么用JSON描述一台设备的完整视觉流程。3. 在vs2019里编译并跑通环境、引用与最小视觉Job3.1 编译前先对齐三件事Halcon版本、DLL复制和license“到手vs2019可以直接编译”是目标状态实际拿到一份框架源码通常要先做三件事对齐环境。第一Halcon运行时版本与开发包版本要一致。电脑上安装的Halcon主版本和引用目录里halcondotnet.dll的版本不一致的话编译能过运行时会直接报底层DLL找不到。还要确认HALCONROOT和HALCONARCH环境变量指向正确Halcon需要通过它们找到算子库# 查看当前Halcon环境变量 echo $env:HALCONROOT echo $env:HALCONARCHHALCONARCH一般应设置为x64-win64并确保VS2019里的目标平台是x64。很多翻车现场就是Debug默认AnyCPUHalcon是64位原生库AnyCPU在64位系统上没大问题但如果项目里存在32位依赖就会在加载阶段崩溃。第二检查halcondotnet.dll的复制策略。在VS2019里选中引用把“复制本地”设为true确保输出目录里有halcondotnet.dll和它依赖的hdevengine.dll。如果源码里的引用是绝对路径比如D:\Halcon\bin\dotnet\halcondotnet.dll换一台电脑就编不过应该改成HintPath相对路径把DLL放进框架源码的lib目录里管理。第三确认Halcon的许可证来源可靠。Halcon作为商业SDK正式授权由官方渠道发放框架里一般会放一个license检查函数。上产线之前一定要用正规且有效的license测试不要拿试用版当生产环境运行到一半提示许可失效整条线停下来的成本远高于license本身。调试阶段遇到license报错优先查环境变量HALCONLICENSE指向的文件是否被误删或过期。注意拿到源码后先不要急着改代码用上面三步把编译环境对齐。改代码之前的环境问题大多数是引用路径和版本不一致造成的。3.2 最小视觉Job读图、建模板、跑一次FindShapeModel框架跑通之后第一个要验证的功能是模板匹配。以螺丝机锁付前定位为例最小流程就是“读一张图 → 用模板图创建模型 → 在搜索图中找目标 → 输出坐标”。代码如下HObject searchImage; HOperatorSet.ReadImage(out searchImage, D:\jobs\screw_top.png); // 模板图提前在HDevelop里裁好只保留目标特征区域 HObject templateImage; HOperatorSet.ReadImage(out templateImage, D:\jobs\screw_template.jpg); HTuple modelID; HOperatorSet.CreateShapeModel( templateImage, // 模板图像 new HTuple(auto), // 金字塔层数 new HTuple(-10.0), // 起始角度 new HTuple(20.0), // 角度范围 new HTuple(auto), // 角度步长 new HTuple(auto), // 优化方式 new HTuple(use_polarity), // 极性表面灰度稳定时优先 new HTuple(15), // MinContrast避免低对比度误匹配 out modelID); HTuple matchedRow, matchedCol, matchedAngle, matchedScore; HOperatorSet.FindShapeModel( searchImage, modelID, new HTuple(-10.0), // 与创建模型的角度范围一致 new HTuple(20.0), // 角度范围 new HTuple(0.7), // MinScore匹配分数阈值 new HTuple(1), // 返回最大匹配个数 new HTuple(0.5), // MaxOverlap防止同一位置多结果 new HTuple(least_squares), // 亚像素定位 new HTuple(0), // 搜索层数 new HTuple(0.8), // Greediness越小越稳但越慢 out matchedRow, out matchedCol, out matchedAngle, out matchedScore);这里的参数直接影响定位稳定性。MinScore设0.7是“宁可漏检也不误检”的思路如果现场特征容易被遮挡可降到0.5但误报会增多。Greediness设0.8速度较快当模板在图像里不明显时降到0.6以下能提高找到概率代价是耗时翻倍。角度范围要和实际机构一致螺丝机如果只有固定角度摆放角度范围设正负5度就够设大了会增加误匹配风险。还有一点要注意HObject是非托管对象用完要调用Dispose否则长时间运行内存会持续上涨。框架里通常会在Job结束后统一释放。3.3 相机接入DirectShow/UVC多相机的稳定区分与线程模型机器视觉框架里相机接入是最容易出“玄学问题”的部分。最常见的是多路USB相机回调里分不清哪一路是哪一路。DirectShow/UVC枚举设备时不能只看FriendlyName因为同一型号相机连电脑后都叫“USB Camera”。稳定做法是用设备路径DevicePath做身份标识// 枚举系统所有视频输入设备 var videoDevices new FilterInfoCollection(FilterCategory.VideoInputDevice); foreach (FilterInfo device in videoDevices) { Console.WriteLine($FriendlyName{device.Name}); Console.WriteLine($DevicePath{device.DevicePath}); }DevicePath是硬件层面的唯一标识形如“\\?\usb#vid_1234pid_5678#...”插拔后重插也能保持稳定。框架里应该把DevicePath写进相机配置而不是用枚举顺序。因为装了两路同型号相机后Windows分配的设备序号不是固定的重启或拔插后会变。相机回调里的线程模型也值得注意。很多框架在相机SDK的回调函数里直接跑FindShapeModel结果界面卡顿、相机帧率暴跌。原因是回调线程属于采集线程不能在里面做耗时操作。正确的做法是生产者-消费者模型private BlockingCollectionHObject _frameQueue new BlockingCollectionHObject(4); // 队列容量4帧 // 相机回调里只做入队 void OnNewFrame(HObject rawImage, string devicePath) { if (!_frameQueue.TryAdd(rawImage.CopyObj(1, -1))) { rawImage.Dispose(); // 队列满了就丢帧 } } // 独立算法线程 void ProcessingLoop() { foreach (HObject frame in _frameQueue.GetConsumingEnumerable()) { VisionResult result ExecuteJob(frame); frame.Dispose(); // 结果交给UI线程显示 } }队列容量设4左右比较合适。容量太小容易丢帧太大延迟高视觉定位的实时性会变差。CopyObj是为了把原始对象复制一份避免相机SDK复用同一块内存。4. 从AOI到螺丝机定位、滤波、检测参数的落地地图4.1 机械手定位 vs 固定工位检测标定方式别选错点胶机、螺丝机、激光切割机这类设备都涉及机械手引导。视觉最终输出的不是像素坐标而是机器人坐标系下的坐标。这里最关键的环节是标定。固定工位检测相机固定在机台上产品移动到相机下方一般用九点标定就够了相机拍9个点记录像素坐标同时记录机械手在这9个位置的机器人坐标然后求一个仿射变换矩阵。用Halcon算子实现很直接HTuple px new HTuple(new double[] { 100, 200, 300, 100, 200, 300, 100, 200, 300 }); HTuple py new HTuple(new double[] { 100, 100, 100, 200, 200, 200, 300, 300, 300 }); HTuple rx new HTuple(new double[] { 10, 50, 90, 10, 50, 90, 10, 50, 90 }); HTuple ry new HTuple(new double[] { 10, 10, 10, 50, 50, 50, 90, 90, 90 }); HTuple homMat2D; HOperatorSet.VectorToHomMat2d(px, py, rx, ry, out homMat2D); // 运行时把模板匹配输出的像素坐标转成机器人坐标 HTuple robotX, robotY; HOperatorSet.AffineTransPoint2d(homMat2D, matchedCol, matchedRow, out robotX, out robotY);标定里最容易踩的坑是行列颠倒。Halcon里像素坐标的X对应的是图像列Y对应行而很多工程师习惯把Row当X直接传给仿射函数结果标定出来的坐标系对角反转。另外如果机械手Z轴会升降点胶高度变化、激光头对焦放大倍率会变需要在不同高度分别标定不能一套矩阵吃到底。机械手引导和固定工位检测在框架里的差异如下表场景是否需要手眼标定标定要点相机固定产品移动九点标定即可标定板贴在载具表面相机装在机械手上眼在手上需手眼标定标定板固定在机台移动多个姿态贴合机对位需要旋转中心补偿标定后还要计算旋转中心与TCP偏差激光切割随动眼在手外Z轴变高多个高度分别做标定4.2 Halcon常用的滤波算法与检测参数先调光再调滤波AOI视觉检测里参数是一层一层试出来的顺序一般是打光 → 曝光/增益 → 滤波 → 阈值分割 → 判定。很多工程师上来就换滤波器想用算法掩盖打光问题这是最常见的弯路。光照方向错了滤波再强也只是把缺陷和背景一起抹平。滤波算法的选择要看噪声类型常用对应关系如下干扰类型推荐滤波器参数经验值椒盐噪声/随机亮点MedianImage3×3或5×5掩膜半径不超过目标特征的一半高斯噪声/传感器噪点GaussFilter标准差1.0~1.5过大边缘会糊表面纹理干扰中值滤波形态学开运算圆形结构元素半径2~5光照渐变背景DynamicThreshold偏移量设正负5~15个灰度级参数单位里掩膜半径和结构元素半径都是像素。实际调试时先放一张只有背景的图看滤波后灰度是否干净再放一张带缺陷的图看缺陷是否保留。两边都满足才算一组可用参数。对于AOI的缺料、划伤检测经典的思路是动态差分先对合格品建一张背景图然后把当前图与背景图做差分超过阈值区域就是候选缺陷。这一步的关键是背景和当前图的灰度环境必须一致所以现场固定曝光和增益很重要。同一套AOI检测程序在白天正常、晚上误报多半就是环境光变化或灯光老化导致的。4.3 把视觉流程装进JSON一个配方文件覆盖一台设备的全部检测项框架源码的价值最终体现在“现场改检测项不用改代码”上。以螺丝机为例检测流程通常是先找定位Mark点再判断螺丝是否漏锁。这个流程用JSON描述如下{ jobName: ScrewDriver-LockCheck, camera: top_camera, steps: [ { name: FindMark, algorithm: ShapeModel, roi: { row: 100, col: 100, width: 400, height: 400 }, params: { minScore: 0.7, greediness: 0.8, angleStart: -10, angleExtent: 20 } }, { name: MissingScrewCheck, algorithm: BlobArea, roi: { row: 80, col: 200, width: 600, height: 500 }, params: { thresholdMin: 80, minArea: 120, maxArea: 5000 } } ] }第一个Step用形状模板匹配找到螺丝孔位中心作为后面检测的基准第二个Step在相对Mark点的固定区域里做Blob分析统计暗色区域的面积。如果螺丝缺失该区域会露出空孔面积或灰度特征明显不同据此判定NG。参数minArea和maxArea的像素值根据相机分辨率和产品实际尺寸换算通常用“缺陷面积占整体区域的百分比”更通用。框架加载JSON后按steps顺序执行每一步的ROI可以沿用上一步输出的坐标做偏移。这就是为什么同一套C#Halcon框架能同时覆盖点胶机、插件机、AOI、激光焊接机和视觉裁板机——设备型号不同只是JSON里的算法类型和参数不同。如果遇到读数类需求比如读扭矩仪或电子秤的显示值思路也一样裁ROI、OCR识别、输出数字再把结果写到通信层而不是每次都改C#主流程。5. 落地避坑C#Halcon框架上产线前的5个翻车现场5.1 启动即崩找不到 halcondotnet.dll 或版本不对现象VS2019编译通过运行时立即弹“未能加载文件或程序集 halcondotnet.dll”。原因大多不是文件缺失而是路径不对或Halcon版本不一致。开发机上Halcon是20.11工控机上装了23.05两个版本的DLL接口有差异。另外只复制了halcondotnet.dll漏掉了它的依赖库。解决把框架用到的Halcon DLL统一放到项目lib目录设置“复制本地”为true在工控机上安装与开发环境一致的主版本Halcon运行时输出目录里应同时存在halcondotnet.dll和hdevengine.dll。5.2 运行两小时报license错最贵的停机原因现象产线调试前一两小时正常运行一段时间后突然报license不合法或找不到许可程序直接退出。原因常见于使用了到期评估license或者license文件绑定的机器特征与工控机不匹配。多台工控机共用一份许可文件也是诱因。解决确认license文件来源正规且与工控机绑定关系正确在框架启动时增加license有效期检查剩余不足7天就在界面上告警把停机风险提前暴露出来。计划性停机换license比产线运行中崩溃代价小得多。注意不要在生产环境使用试用license做长时间运行验证。侥幸省下的成本会在验收当天翻倍还回去。5.3 相机回调里直接跑算法画面卡死现象不跑视觉流程时相机预览流畅一触发检测相机画面冻结UI线程也跟着假死。原因相机SDK的回调函数运行在采集线程直接在回调里调用FindShapeModel、Blob分析等耗时算子会阻塞采集线程同时UI线程直接等待检测结果整个软件的响应被拖死。解决按第3.3节的BlockingCollection模型拆分线程相机回调只入队算法线程消费。框架里要强制遵守这个约定否则后续加延时拍照或二次识别时照样卡。换句话讲检测算法的执行时间可以长但绝不能占着采集回调。5.4 多相机分不清回调里的CameraIndex并不可靠现象设备加装第二路相机后流程A拿到的图像其实是流程B的产品错检。原因UVC设备枚举顺序是系统按插入顺序分配的重启或拔插后索引会变。回调参数里的CameraIndex只是下标不是硬件标识。解决枚举阶段用DevicePath做标识配置里绑定每路相机的DevicePath回调里也按DevicePath分发图像。框架源码如果还在用“第0路、第1路”这样的开关参数建议改掉。这是多相机设备上返工率最高的一个问题。5.5 白天正常晚上误报光照才是检测稳定性最大的玄学现象AOI检测白班良率正常晚班同一套参数误报增高同一台点胶机上午定位准、下午偶尔偏。原因自然光变化、照明灯老化、产品表面反光角度改变都会让灰度分布漂移。滤波器参数和环境光强是耦合的白天调的阈值晚上不再适用。解决把相机曝光和增益锁死尽量在暗室环境或加遮光罩框架里加一层“图像质量预检”——统计当前图的灰度均值与直方图范围若超出训练时记录的区间先报警提示光照异常而不是继续跑检测。这个预检几行代码就能做却能把“光照玄学”变成可追踪的报警。6. 进阶验证把它改造成能扛住产线的平台6.1 三个验收动作压测、断线重连、标定复验框架拿到手建议先做三个验证动作。第一是压测连续运行500次视觉Job统计单帧耗时的平均值和最大值同时观察内存涨幅。用Halcon的计时算子可以做最基础的耗时统计HTuple t1, t2; HOperatorSet.CountSeconds(out t1); for (int i 0; i 500; i) { VisionResult result job.Execute(image); } HOperatorSet.CountSeconds(out t2); double avgMs (t2.D - t1.D) / 500.0 * 1000.0; int maxWaitMs 100; // 按设备节拍换算平均耗时必须小于设备节拍的一半否则后面加通信、加IO判断就没有余量。第二是断线重连运行中拔掉相机USB线再插回观察框架能否自动重连、队列是否堆积。很多框架能做到不崩但重连后回调失效这不行。第三是标定复验用同一块标定板在相机视野内放5个位置重复定位10次记录坐标标准差。稳定框架的重复精度应该在0.05毫米以内超过这个数就检查机械震动和相机固定是否松动。6.2 把它变成你的平台先加固相机层再把调试工具做厚如果决定长期在这个框架上迭代我的建议是先加固相机抽象层再丰富调试工具。相机层要支持多品牌切换和断线事件这是设备长期运行的基础调试工具则要做图像缓存、参数热加载、结果日志三件套。图像缓存能让你在现场复现“刚才那张NG图”参数热加载能让你不重启程序就调阈值结果日志能追溯每一个NG品的视觉数据。这三样做好现场调试效率会翻倍。我接手任何机器视觉框架源码第一件事永远不是看窗体界面而是把相机封装和Job执行器拉出来读。这两个地方决定了一台设备能跑多快、多稳。你先照着这个思路把现有框架跑通再顺着边界去替换实现会比直接改业务代码稳妥得多。希望帮到你。本文还有配套的精品资源点击获取
