Halcon与C#工业视觉系统五模块工程实践

1. 这不是“调个库”那么简单：Halcon与C#联合编程的真实战场

你搜“halcon c#”出来的教程，十有八九是“新建项目→引用dll→写几行HObject代码→显示一张图”，然后戛然而止。但现实里，一个能落地的工业视觉系统，从来不是在VS里点几下就跑通的玩具。它是一整套闭环：相机得听你的话（控制），图像得让你看得清（平移缩放），每一步操作都得留痕（日志），关键任务得扛住压力（缺陷检测），最后还得指挥设备动起来（路径规划）。这五个模块，任何一个卡壳，整条产线就得停。

我做过三个量产级项目，最深的体会是：Halcon不是图像处理库，它是工业视觉的“操作系统内核”；C#不是界面语言，它是整套系统的“调度中枢”。两者联合，本质是让高精度、高确定性的底层算法（Halcon）和灵活、可扩展、易维护的上层业务逻辑（C#）各司其职。比如，Halcon负责在0.8毫秒内算出一个焊点的圆心坐标，而C#负责判断这个坐标是否在公差带内、记录到数据库、触发报警灯、再把修正量发给PLC——这中间的毫秒级时序、内存管理、异常隔离，才是真正的难点。

标题里的五个关键词，背后全是硬骨头。“相机控制”不是简单调用Open和Grab，而是要处理不同厂商SDK（Basler、Hikvision、MindVision）的异步回调、帧率抖动、曝光同步；“图像平移缩放”不是拖拽鼠标那么简单，得解决双缓冲闪烁、GPU加速失效、ROI区域实时更新、缩放后坐标系映射等一堆UI层的坑；“日志记录”在工业现场意味着不能丢一条记录，得考虑断电保护、磁盘满自动轮转、多线程写入冲突；“缺陷检测”更不是套个模板匹配就完事，得面对光照变化、工件微小位移、同类缺陷形态差异大等真实干扰；最后的“路径规划”，往往要对接运动控制卡或PLC，协议解析、指令校验、超时重试，一个都不能少。

所以，这篇内容不讲“怎么安装Halcon”，也不讲“HObject怎么赋值”，而是直接切入一个真实产线场景：电机转子绕线质量检测系统。我会把这五个模块如何咬合、数据如何流转、坑在哪里、怎么填，掰开揉碎了讲清楚。如果你正被“Halcon和C#怎么真正用起来”这个问题卡住，或者你的项目已经跑起来了但总在某个环节莫名崩溃，那接下来的内容，就是你该抄的作业。

2. 整体架构设计：为什么必须分层？为什么不能全扔进HDevelop？

2.1 五模块的职责边界与数据流

很多初学者一上来就想“用C#把Halcon所有功能都封装一遍”，结果越写越乱。正确的思路是画一张“数据流图”，明确每个模块只干一件事，且接口干净。

• 相机控制层（C#主导）：职责是“拿到原始图像”。它不关心图像里有什么，只负责：初始化SDK、设置曝光/增益/触发模式、启动采集、接收每一帧的byte[]或IntPtr。输出是一个带时间戳的原始图像缓冲区。这里的关键是解耦：Halcon不碰SDK，C#也不碰Halcon的图像处理算子。我们用一个CameraFrameEventArgs事件来传递数据，避免任何跨线程访问Halcon对象。

• 图像处理层（Halcon主导）：职责是“从图像里挖出信息”。输入是上层传来的原始图像（HObject），输出是结构化结果（HTuple坐标、HRegion缺陷区域、HImage处理后图）。它完全不知道相机型号，也不知道结果要发给谁。所有参数（如阈值、模板大小）都通过HTuple传入，保证可配置性。

• UI交互层（C#主导）：职责是“让人看懂、能操作”。它接收Halcon处理后的HImage，在WPF的Image控件上渲染；实现平移缩放，核心是维护一个TransformGroup，里面包含TranslateTransform和ScaleTransform，所有鼠标滚轮、拖拽操作都只改这两个对象的属性；同时，它要把用户在界面上框选的ROI区域，实时转换成Halcon坐标系下的矩形，传给处理层。这里最大的陷阱是坐标系错位：WPF的(0,0)在左上角，Halcon默认也是左上角，但缩放后，鼠标位置和图像像素位置的映射关系会变，必须用InverseTransform反向计算。

• 日志与状态层（C#主导）：职责是“记住一切”。它不参与图像处理，只监听两个事件：一是相机层的“新帧到达”，记录时间戳、帧号、曝光值；二是处理层的“检测完成”，记录缺陷类型、位置、置信度、耗时。日志文件按天分割，单个文件超过50MB自动归档，用ConcurrentQueue<T>做生产者-消费者队列，避免UI线程阻塞。关键点是：所有日志写入必须异步且带重试，我见过太多项目因为磁盘IO慢，导致整个采集线程卡死。

• 决策与执行层（C#主导）：职责是“做出判断并行动”。它接收处理层的结果，比如“绕线偏移量X=0.15mm，Y=-0.08mm”，然后查工艺数据库，判断是否超差；如果超差，生成一个修正路径（比如让伺服电机沿X轴正向移动0.15mm），通过Modbus TCP发给运动控制器；同时触发声光报警，并把这条记录标记为“已处理”。这里的核心是状态机：从“等待触发”→“采集中”→“处理中”→“决策中”→“执行中”，每个状态都有超时保护，防止死锁。

这五个模块的数据流，就像一条流水线：相机产出“毛坯”（原始图）→ 处理层加工成“零件”（坐标/区域）→ UI层展示“零件”并允许人工干预 → 日志层给每个环节打上“时间戳钢印” → 决策层根据“零件规格”下达“返工指令”。任何一环脱节，整条线就停摆。

2.2 为什么Halcon不能直接写UI？为什么C#不能硬刚算法？

这是新手最容易犯的战略错误。我拿一个真实案例说：有个团队想用HDevelop写一个带缩放的图像查看器，结果发现HDevelop的dev_display在缩放时严重卡顿，帧率从30fps掉到3fps。他们折腾了两周，最后发现HDevelop的显示控件压根没做GPU加速，它只是把HImage转成Bitmap再贴到WinForm上，每次缩放都要重绘整个位图。

反过来，如果强行用C#写缺陷检测，比如自己实现一个模板匹配，你会发现：第一，速度慢，C#的for循环遍历像素，比Halcon的SIMD指令集慢5-10倍；第二，精度低，Halcon的亚像素插值、边缘拟合，C#要自己写数学公式，一个浮点误差就导致定位漂移0.5像素；第三，维护难，一个新需求要改算法，你得在C#里重写几百行数学代码，而Halcon里可能就一个find_shape_model算子加几个参数。

所以，分工的本质是扬长避短：Halcon的强项是“确定性计算”——同样的输入，永远给出同样的、高精度的输出，这是工业检测的生命线；C#的强项是“不确定性调度”——处理用户点击、网络中断、PLC无响应、磁盘满了等各种意外，这是系统稳定性的保障。把Halcon当“计算器”，把C#当“指挥官”，这才是正道。

2.3 工程化取舍：性能、可维护性、调试便利性的三角平衡

在真实项目里，没有银弹，只有权衡。举三个典型取舍：

• 内存 vs 速度：Halcon处理一张图，会产生多个中间HObject（比如二值化图、连通域图、轮廓图）。全保留？内存爆炸。全释放？下次要用还得重算。我们的方案是：定义一个HImageCache类，用WeakReference缓存最近3次处理的中间图，键是处理参数的哈希值。这样既避免重复计算，又不会OOM。实测下来，内存占用降了60%，而平均处理时间只增加了0.3ms。

• 日志粒度 vs 磁盘IO：记录每一帧的原始曝光值？还是只记录“异常帧”的？我们选后者。在相机层加一个“曝光波动检测器”，如果连续5帧曝光值标准差>10，才记录详细日志。这样日志量减少90%，但关键问题一个不漏。

• Halcon版本 vs C#生态：Halcon 20.11支持.NET Core，但很多老设备SDK只支持.NET Framework 4.7.2。我们最终选择“双框架共存”：主程序用.NET 6，相机SDK用独立的.NET Framework 4.7.2进程，通过命名管道通信。虽然多了一层IPC开销（约0.2ms），但换来了整个系统的现代化和长期可维护性。

这些取舍，没有标准答案，只有基于你具体产线的判断。我的建议是：先搭一个最小可行系统（MVP），只实现“相机采集+显示+单次检测”，跑通全流程，再逐个模块优化。别一上来就想造火箭。

3. 核心细节拆解：从代码片段到工业级鲁棒性

3.1 相机控制：不止是Open()和Grab()

工业相机的“控制”，远不止打开和抓图。它涉及硬件同步、参数动态调整、异常恢复。以Basler ace系列为例，核心难点在三个地方。

第一，触发模式与帧率稳定性。自由运行模式（Free Run）下，相机自己决定帧率，但实际产线需要“来料触发”——传感器检测到工件到位，才拍一张。这就必须用硬件触发（Hardware Trigger）。在C#里，你要调用camera.Parameters[PLCamera.TriggerSelector].SetValue(PLCamera.TriggerSelector.FrameStart)，再设TriggerSource = Line1。但坑来了：如果触发信号是5V TTL，而相机输入是12V，直接接会烧IO口。我们在线路里加了一个光耦隔离模块，成本2块钱，却避免了整台相机报废。

第二，参数动态调整的时序。你想在检测前临时调高曝光，但ExposureTimeAbs的设置不是立即生效的。Basler文档里写得很清楚：“Parameter changes take effect on the next frame start”。这意味着，你必须在触发信号发出前，至少预留1帧的时间（比如33ms@30fps）来设置参数。我们的做法是：在收到“准备检测”指令后，立刻设置曝光，然后发一个“dummy trigger”（空触发），等这一帧过去，再发正式触发。代码里用Task.Delay(35)是不可靠的，必须用相机自身的帧同步信号。

第三，异常恢复机制。相机掉线怎么办？不能让整个软件崩掉。我们设计了一个CameraHealthMonitor类，它定期（每5秒）发送一个GetDeviceInfo命令。如果超时，就执行三步：1）调用camera.Close()；2）等待2秒；3）重新Open()并恢复所有参数。关键点是：所有参数（包括自定义的LUT表、白平衡系数）都序列化到XML文件，Open()后自动加载。这个机制让我们在一次客户现场测试中，成功扛住了电源波动导致的17次相机重启，而产线只延迟了不到2秒。

// Basler相机健康检查示例 public class CameraHealthMonitor { private readonly PylonCamera _camera; private readonly Timer _healthTimer; private readonly string _configPath = "camera_config.xml"; public CameraHealthMonitor(PylonCamera camera) { _camera = camera; _healthTimer = new Timer(CheckHealth, null, TimeSpan.FromSeconds(5), TimeSpan.FromSeconds(5)); } private void CheckHealth(object state) { try { // 发送轻量级命令，不读图像 var deviceInfo = _camera.Parameters[PLCamera.DeviceInfo].GetValue(); // 成功，啥也不做 } catch (Exception ex) { Log.Error($"Camera health check failed: {ex.Message}"); RecoverCamera(); } } private void RecoverCamera() { try { _camera.Close(); // 必须先关闭 Thread.Sleep(2000); _camera.Open(); LoadConfig(_configPath); // 恢复所有参数 Log.Info("Camera recovered successfully"); } catch (Exception ex) { Log.Error($"Camera recovery failed: {ex.Message}"); } } }

提示：所有相机SDK的异常，都必须捕获PylonRuntimeException（Basler）或HResultException（Hikvision），而不是泛泛的Exception。前者包含了硬件错误码，能精准定位是“曝光超时”还是“内存不足”。

3.2 图像平移缩放：WPF里的像素级精准控制

在WPF里实现一个工业级的图像查看器，核心挑战是“零失真”和“零延迟”。很多人用ScrollViewer，结果一缩放就糊，一拖拽就卡。正确姿势是：自己管理变换矩阵，自己绘制图像。

我们弃用Image控件，改用WriteableBitmap+DrawingVisual。流程是：Halcon处理完HImage，用GetImagePointer1拿到原始像素指针，然后用CopyPixels拷贝到WriteableBitmap的后台缓冲区。缩放和平移，不靠控件属性，而是靠修改WriteableBitmap的RenderTransform。

关键代码在鼠标滚轮事件里：

private void ImagePanel_PreviewMouseWheel(object sender, MouseWheelEventArgs e) { var mousePos = e.GetPosition(ImagePanel); var scaleDelta = e.Delta > 0 ? 1.1 : 0.9; // 滚轮向上放大 // 计算缩放中心点（鼠标位置）在图像坐标系中的位置 var imagePoint = TransformToImageSpace(mousePos); // 更新缩放因子 _currentScale *= scaleDelta; _currentScale = Math.Clamp(_currentScale, 0.1, 10.0); // 限制缩放范围 // 更新平移量，保证缩放中心点在屏幕上位置不变 _offsetX += (mousePos.X - _offsetX) * (scaleDelta - 1); _offsetY += (mousePos.Y - _offsetY) * (scaleDelta - 1); // 应用变换 ApplyTransform(); } private Point TransformToImageSpace(Point screenPoint) { // 将屏幕坐标（相对于ImagePanel左上角）转换为图像坐标（相对于原始图像左上角） var scaleX = _currentScale * _originalWidth / ImagePanel.ActualWidth; var scaleY = _currentScale * _originalHeight / ImagePanel.ActualHeight; return new Point( (screenPoint.X - _offsetX) / scaleX, (screenPoint.Y - _offsetY) / scaleY ); }

这段代码的精妙之处在于TransformToImageSpace：它把用户直观的“鼠标在屏幕上点的位置”，实时映射回“这张图的哪个像素点”。这样，无论你缩放到多大，拖拽到哪里，用鼠标框选一个区域，得到的永远是真实的像素坐标，可以直接喂给Halcon的reduce_domain算子做ROI处理。我们实测，在4K显示器上缩放到2000%，拖拽依然流畅，CPU占用<5%。

注意：WriteableBitmap的Lock()和Unlock()必须成对出现，且Unlock()后才能调用InvalidateVisual()刷新。漏掉Unlock()会导致内存泄漏，这是个经典坑。

3.3 日志记录：工业现场的“黑匣子”

工业日志不是Console.WriteLine，它必须满足三个硬指标：不丢、不乱、不爆。

• 不丢：用ConcurrentQueue<LogEntry>做内存缓冲，主线程只往队列里Enqueue，一个独立的LoggerThread从队列里TryDequeue并写入文件。即使磁盘IO卡住，内存队列最多存10000条，之后Enqueue会返回false，此时触发“本地缓存”——把日志写到一个临时的SQLite数据库里，等磁盘恢复再同步。

• 不乱：多线程写同一个文件必然乱序。我们的方案是：所有日志条目都带一个long TimestampTicks = DateTime.UtcNow.Ticks，写入文件时，按这个时间戳排序。LoggerThread每次写入前，先Sort()内存队列，再批量写入。这样，即使A线程的日志比B线程晚生成，但时间戳早，也会排在前面。

• 不爆：单个日志文件限制50MB，按日期命名（log_20240520.txt）。当文件达到阈值，就关闭当前文件，新建一个。旧文件自动压缩为.zip，并删除超过30天的压缩包。这个逻辑封装在RotatingFileLogger类里，一行代码启用：logger = new RotatingFileLogger(@"C:\logs", maxSizeMB: 50, keepDays: 30);

日志内容也讲究。我们定义了四级：

• INFO：正常流程，如“第12345帧采集完成，曝光12500us”
• WARN：潜在风险，如“ROI区域超出图像边界，已自动裁剪”
• ERROR：功能失败，如“Halcon模板匹配失败，置信度0.23 < 阈值0.7”
• FATAL：系统崩溃，如“相机SDK初始化失败，错误码0x80070005”

最关键的是，每条日志都带CorrelationId——一个GUID。从相机触发、到图像处理、到路径规划、到PLC响应，所有相关日志都用同一个ID。查问题时，只要搜一个ID，就能串起整个事务链。这比看几十个分散的日志文件高效十倍。

3.4 缺陷检测：从“能检出来”到“检得准、检得稳”

标题里的“缺陷检测”，在电机转子绕线场景，具体指：检测漆包线是否错位、是否叠绕、是否有断线、绝缘胶带是否覆盖到位。这绝不是threshold一下就完事。

我们采用“多尺度+多特征”融合策略。第一步，用Halcon的inspect_shape_model在粗尺度（图像缩小4倍）上快速定位绕线区域的大致位置；第二步，把该区域抠出来，放大到原图尺寸，用edges_sub_pix提取亚像素边缘；第三步，用fit_circle_contour_xld拟合出理想绕线的圆心和半径；第四步，计算每根实际绕线中心点到理想圆心的距离，距离>0.15mm即判为“偏移缺陷”。

但真实世界有干扰。光照不均会让局部阈值失效。我们的对策是：不用全局阈值，而用illuminate算子做背景校正。它先用一个大半径的mean_image生成背景图，再用原图减去背景图，得到光照均匀的图像。这个算子在Halcon里叫“背景抑制”，效果立竿见影。

另一个坑是“伪缺陷”。绕线表面有反光亮点，会被误认为断线。我们加了一步“纹理验证”：用texture_laws算子计算该区域的纹理能量，如果能量值低于阈值，说明是光滑反光，不是真实的断线缺口。这个参数（纹理能量阈值）不是固定值，而是根据当天的环境光强度动态调整——我们用一个额外的小相机监控车间亮度，把亮度值作为参数传给Halcon。

最后是“检得稳”。Halcon的算子结果，有时会因为噪声跳变。我们引入“滑动窗口滤波”：不依赖单帧结果，而是看连续5帧的检测结果，用中值滤波（median）输出最终值。代码在C#里实现：

// 滑动窗口中值滤波器，用于稳定Halcon检测结果 public class MedianFilter<T> where T : IComparable<T> { private readonly Queue<T> _window = new Queue<T>(); private readonly int _size; public MedianFilter(int size) => _size = size; public T Filter(T newValue) { _window.Enqueue(newValue); if (_window.Count > _size) _window.Dequeue(); var list = _window.ToList(); list.Sort(); return list[list.Count / 2]; } } // 使用 var positionFilter = new MedianFilter<double>(5); double stableX = positionFilter.Filter(halconResult.X);

这套组合拳下来，误报率从最初的12%降到0.8%，漏检率从5%降到0.3%，达到了客户要求的SPC过程能力指数Cpk>1.33。

3.5 路径规划：让视觉结果真正驱动产线

缺陷检测的终点，不是弹个MessageBox，而是让设备动起来。在电机转子场景，“路径规划”特指：根据绕线偏移量，生成一组伺服电机的运动指令，让机械手微调转子位置，使下一次绕线回到公差内。

这里的关键是坐标系转换。Halcon算出的偏移量（单位：像素），要变成伺服电机的脉冲数。转换公式是：脉冲数 = 像素偏移 × 像素当量（um/pixel） × 电机分辨率（pulse/um）。

• 像素当量怎么标定？我们用一个高精度千分尺（0.001mm）在图像里移动一个已知距离，比如1mm，看它占多少像素。实测下来，这个值不是常数，会随镜头焦距、工作距离变化。所以我们在软件里做了“标定向导”：用户用千分尺移动1mm，点击两次图像，软件自动计算并保存当前焦距下的像素当量。

• 电机分辨率由硬件决定，比如松下A6系列伺服，电子齿轮比设为1:1时，是10000 pulse/rev，丝杠导程5mm，则1um = 2 pulse。这个值固化在配置文件里。

路径规划的输出，不是单个数值，而是一个MotionCommand对象：

public class MotionCommand { public string Axis { get; set; } // "X" or "Y" public double TargetPosition { get; set; } // 单位：mm public double Velocity { get; set; } // mm/s public double Acceleration { get; set; } // mm/s² public Guid CorrelationId { get; set; } // 关联到哪次检测 }

这个对象通过Modbus TCP发给运动控制器。我们用NModbus4库，但不直接调用WriteMultipleRegisters，而是封装了一个MotionControllerClient类，它内置了三次握手：发指令→等控制器返回ACK→再发确认。如果1秒内没收到ACK，自动重发，最多3次。重试失败则记FATAL日志，并触发急停。

实操心得：路径规划的“安全边界”比精度更重要。我们强制所有TargetPosition必须在[-2.0, +2.0]mm范围内，超出则拒绝执行，并报警。宁可不修，也不能修过头撞机。

4. 实操全流程：从VS新建项目到产线跑通

4.1 环境搭建：避开Halcon安装的十大雷区

Halcon安装，看似简单，实则暗坑无数。我整理了最常踩的十个雷，按严重程度排序：

1. 雷区1：混用32/64位（致命）。Halcon Runtime必须和你的C#项目平台目标一致。如果你的C#项目是x64，但装了Halcon-20.11.1.0-win32，运行时会报BadImageFormatException。解决方案：永远下载win64版本，C#项目属性→生成→平台目标→选x64。

2. 雷区2：环境变量污染。Halcon安装会往PATH里加一堆路径，如果之前装过旧版，路径冲突会导致HalconDotNet.dll找不到。解决方案：安装后，手动检查系统环境变量PATH，只保留最新版的C:\Program Files\MVTec\HALCON-20.11.1.0\bin\x64sse2-win64这一条，删掉所有其他Halcon路径。

3. 雷区3：.NET版本不匹配。Halcon 20.11支持.NET 5/6/7，但不支持.NET 8（截至2024年5月）。如果你用VS2022创建.NET 8项目，会编译失败。解决方案：C#项目文件里，<TargetFramework>net6.0</TargetFramework>，别贪新。

4. 雷区4：缺少VC++运行库。Halcon依赖vcruntime140.dll等，如果客户电脑没装VS2015-2019的运行库，程序直接闪退。解决方案：在安装包里打包vc_redist.x64.exe，安装时静默运行。

5. 雷区5：License权限不足。Halcon的浮动许可（Floating License）需要网络连通License Server，而很多工厂内网是断的。解决方案：申请一个Node-Locked许可，绑定到这台电脑的MAC地址，离线可用。

6. 雷区6：HDevelop和C#混用路径。HDevelop里写的HDevEngine脚本，路径是相对HDevelop工程的，但C#里调用时，路径是相对于C#可执行文件的。解决方案：所有HDevEngine脚本，用AppDomain.CurrentDomain.BaseDirectory拼接绝对路径。

7. 雷区7：Halcon DLL未复制到输出目录。VS默认不把HalconDotNet.dll复制到bin\x64，导致运行时报DllNotFoundException。解决方案：在项目引用里，右键HalconDotNet→属性→“复制本地”设为True。

8. 雷区8：Halcon资源未释放。Halcon对象（HObject,HWindow）必须显式调用Dispose()，否则内存泄漏。解决方案：所有Halcon对象，用using语句包裹，或在IDisposable接口里统一释放。

9. 雷区9：Halcon线程模型误解。Halcon的HDevEngine是线程安全的，但HWindow不是。多个线程不能同时往同一个HWindow里disp_obj。解决方案：每个线程用独立的HWindow，或加lock。

10. 雷区10：Halcon版本升级兼容性。Halcon 20.11的HDevEngine脚本，不能直接在21.05里运行，会报HDevEngineException。解决方案：重大升级前，用Halcon自带的hdev_engine_converter工具批量转换脚本。

装完后，用一段最简代码验证：

// Program.cs using HalconDotNet; class Program { static void Main(string[] args) { try { // 初始化Halcon HOperatorSet.SetSystem("width", 1920); HOperatorSet.SetSystem("height", 1080); // 创建一张测试图 HObject testImage; HOperatorSet.GenImageConst(out testImage, "byte", 640, 480); HOperatorSet.FillUp(testImage, out HObject filled); Console.WriteLine("Halcon初始化成功，测试图生成完成！"); filled.Dispose(); testImage.Dispose(); } catch (Exception ex) { Console.WriteLine($"Halcon初始化失败：{ex.Message}"); } } }

能打印出“初始化成功”，说明环境OK。否则，按上面十大雷区逐一排查。

4.2 项目结构：一个可维护的工业级解决方案

一个能活过三年的项目，结构比代码更重要。我们采用“垂直切片”而非“水平分层”，即每个功能模块（相机、处理、UI）都是一个独立的、可测试的项目。

解决方案结构如下：

MotorRotorInspection.sln ├── Core/ // 核心库，放Halcon封装、日志、通用工具 │ ├── HalconWrapper.cs // 封装HDevEngine调用、HObject生命周期管理 │ ├── Logger.cs // RotatingFileLogger实现 │ └── Utils.cs // 坐标转换、图像格式转换等 ├── CameraDrivers/ // 相机驱动，每个厂商一个项目 │ ├── BaslerDriver/ // Basler Pylon SDK封装 │ └── HikvisionDriver/ // 海康MVSDK封装 ├── VisionAlgorithms/ // Halcon算法，每个检测项一个HDevEngine脚本 │ ├── WireOffset.hdev // 绕线偏移检测 │ ├── BreakDetection.hdev // 断线检测 │ └── InsulationCheck.hdev // 绝缘胶带检测 ├── UI/ // WPF主程序 │ ├── MainWindow.xaml // 主界面，含图像显示、按钮、状态栏 │ ├── ImagePanel.cs // 自定义控件，实现缩放拖拽 │ └── ViewModel/ // MVVM，绑定命令和状态 ├── MotionControl/ // 运动控制，Modbus TCP客户端 │ └── ModbusClient.cs └── Tests/ // 单元测试，用Halcon的test_image模拟输入

这种结构的好处是：更换相机，只动CameraDrivers项目；优化算法，只改VisionAlgorithms里的.hdev脚本；升级UI，不影响底层。我们曾用这个结构，在客户现场，3小时内把Basler相机换成海康相机，全程无需修改UI和Core项目。

4.3 关键代码实现：五模块的粘合剂

所有模块的粘合，靠一个VisionSystem类。它不是上帝类，而是一个协调者，定义了清晰的事件和委托。

// Core/VisionSystem.cs public class VisionSystem : IDisposable { // 事件：新图像到达 public event EventHandler<CameraFrameEventArgs> NewFrameArrived; // 事件：检测完成 public event EventHandler<DetectionResultEventArgs> DetectionCompleted; // 事件：路径规划完成 public event EventHandler<MotionCommand> PathPlanned; private readonly CameraDriver _camera; private readonly HalconProcessor _processor; private readonly MotionControllerClient _motion; public VisionSystem(CameraDriver camera, HalconProcessor processor, MotionControllerClient motion) { _camera = camera; _processor = processor; _motion = motion; // 订阅相机事件 _camera.NewFrameArrived += OnNewFrame; // 订阅处理完成事件 _processor.DetectionCompleted += OnDetectionCompleted; } private void OnNewFrame(object sender, CameraFrameEventArgs e) { // 在独立线程处理，避免阻塞相机采集 Task.Run(() => ProcessFrame(e)); } private void ProcessFrame(CameraFrameEventArgs e) { try { // 1. 调用Halcon处理 var result = _processor.Process(e.Image, e.Timestamp); // 2. 触发检测完成事件 DetectionCompleted?.Invoke(this, new DetectionResultEventArgs(result)); // 3. 如果有缺陷，规划路径 if (result.HasDefects) { var command = PlanPath(result); PathPlanned?.Invoke(this, command); _motion.SendCommand(command); } } catch (Exception ex) { Log.Error($"Frame processing failed: {ex}"); } } private MotionCommand PlanPath(DetectionResult result) { // 核心算法：像素偏移到脉冲数转换 var xPulse = (int)(result.OffsetX * _pixelToPulseX); var yPulse = (int)(result.OffsetY * _pixelToPulseY); return new MotionCommand { Axis = "XY", TargetPosition = new[] { xPulse, yPulse }, Velocity = 1000, Acceleration = 5000, CorrelationId = result.CorrelationId }; } }

这个类的精妙在于：它把“相机→处理→决策→执行”的链条，变成了事件驱动的松耦合。UI层只需要订阅DetectionCompleted事件，就能更新界面；日志层订阅所有事件，就能记录全链路；测试层可以Mock掉CameraDriver和MotionControllerClient，只测ProcessFrame逻辑。这就是工业软件的可测试性。

4.4 产线部署与验证：从实验室到车间的最后一步

在实验室跑通，不等于产线能用。我们有一套标准化的产线验证清单：

1. 环境验证：检查客户电脑是否装了VC++2015-2019运行库、.NET 6 Desktop Runtime、Halcon Runtime。用一个CheckEnvironment.exe小工具一键扫描。

2. 硬件验证：用CameraTestTool单独测试相机，确认能稳定采集30分钟不掉帧；用MotionTestTool单独测试伺服，确认能按指令精准移动。

3. 算法验证：提供100张标注好的“黄金样本图”，涵盖各种缺陷类型和光照条件。运行AlgorithmValidator，输出报告：准确率、召回率、单帧处理时间。要求准确率≥99.5%，召回率≥99.0%，时间≤80ms。

4. 压力验证：用StressTestTool模拟连续采集10000帧，检查内存是否稳定（增长<50MB）、日志是否完整（10000条不丢）、CPU是否过热（<80℃）。