植板系统v2.1：C#集成Halcon与拖拽式PLC编程实战

做了这么多年设备上位机我最怕的不是算法写不出来而是现场操作员拿着一个要改代码才能调参数的程序。最近把一套植板控制系统从老框架里彻底拆了重写推到 v2.1核心其实就三件事用 C# 把 Halcon 视觉框架完整集成进上位机、用拖拽式编程替代硬编码流程、再把 PLC 指令的生成变成可视化配置。这篇把系统的设计思路、关键代码结构和现场踩过的坑一次说清楚。搞设备集成的工程师、做视觉定位的同学以及所有被调一个点就要改源码折磨过的人应该都能从这里拿到点能直接用东西。1. 植板设备到底在控什么v2.1 要解决的三个核心麻烦1.1 植板工艺控制链路的基本盘先把这个系统对应的设备形态说清楚。所谓植板机是把电子元件、端子或者定位柱按指定坐标安装到基板上的自动化设备。核心动作链路并不复杂基板到位、相机拍照、视觉识别出目标孔位坐标、运动机构移动到位、执行植板动作、产品流出。听起来简单但生产现场跑起来之后麻烦全藏在细节里。v2.1 版的控制系统对应的是三联机结构上料传输、视觉定位工位、植板执行工位。这套系统最要命的地方不是单个工位难写而是三个工位的节奏必须对齐。传输皮带有测速编码器视觉工位拍照要在基板运动到指定区间内完成植板工位的 XYZ 轴在动作时不能和皮带干涉。任何一个环节多耽误几十毫秒节拍就崩了。老版本用顺序式硬编码处理这个问题拍照函数执行完再算坐标再写 PLC 寄存器再等到位信号。代码听上去逻辑通顺但现场一旦要加一个拍照前先吹气清灰的动作就得重新编译换了一款相机调用的采集类又得拆开改。整个控制程序变成一团谁也动不得的意大利面这是是我下决心重构的第一个原因。1.2 视觉系统与 PLC 两层皮的痛点第二个麻烦更隐蔽视觉和 PLC 之间只有一包寄存器没有任何中间层。Halcon 定位出的像素坐标被上位机换算成机械坐标后写进 PLC 指定地址PLC 再拿去跑插补运动。逻辑上没问题但现场调机的时候很痛苦。举个例子调机工程师觉得植板位置整体偏了 0.3 毫米。在硬编码的老系统里他不能自己改补偿值得让上位机开发改代码里的偏移常量、重新编译发布。哪怕我用 XML 做配置文件每次改参数仍然要重启软件。换产品型号的时候一整套流程参数要手工在几个配置文件之间来回切一不小心就漏了某个坐标换算系数。生产线等着出货开发人员被拉去改一个常量这种场景经历过一次就再也不想经历第二次。v2.1 的设计目标就是把这些东西全部可视化流程节点在画布上拖定位参数在界面里改PLC 动作序列由节点自动生成整个换型时间从等开发改代码压缩到操作员自己拖节点调参数。后面几节展开讲每一层的实现。2. Halcon 集成层C# 项目里视觉模块不是调接口那么简单2.1 图像采集链路原生窗口显示与算子线程分离Halcon 在 C# 里的集成第一件事就是引包。安装 Halcon 后在项目里引用 halcondotnet.dll然后 using HalconDotNet。很多初学者把 Halcon 的拍照、定位、显示全写在一个 UI 线程里面程序一跑界面就卡死刷新率低的像幻灯片这是集成最容易翻车的点。v2.1 里我拆成了三层采集层、处理层、显示层。采集层单独一个线程负责调用 GrabImageAsync 循环抓图抓到的 HObject 图像交给处理管线显示层通过 HWindowControl 的 BeginPaint/EndPaint 机制把图像推过去。显示控件本身是 UI 控件跨线程操作必须走 Invoke但直接锁 Invoke 会把处理线程卡死所以我的做法是把显示刷新也做成一个独立的高频任务UI 线程只负责消费显示队列里最新的一帧。private void CaptureLoop() { HTuple windowHandle _window.HalconWindow; while (_isRunning) { try { _camera.GrabImageAsync(out HObject image, -1); _latestFrame image.Clone(); _producer.Enqueue(_latestFrame); // 显示队列只保留最新帧避免界面显示堆积 } catch (HalconException ex) { LogError($采集异常: {ex.GetErrorMessage()}); Thread.Sleep(200); } } }这里有个细节值得强调GrabImageAsync 的第二个参数传 -1表示最长等待一帧的时间不设上限按轮询模式来。如果相机掉线这个调用会一直阻塞线程看起来就像卡死了。所以采集线程必须能响应设备重启我加了一个超时控制用 WaitForNextFrame 配合相机自带的采集超时参数一旦超时立刻重连而不是死等。2.2 模板匹配与手眼标定的封装取舍定位这一层v2.1 没有把所有 Halcon 算子都暴露出来而是收口成几个可配置的定位工具模板匹配、Blob 分析、卡尺找边。每个工具都有标准输入输出界面里配置参数底层算子封装成独立类。模板匹配用的核心算子是 create_shape_model 和 find_shape_model这两个算子参数很多MinScore、AngleStart、AngleExtent、NumLevels 随便调一调结果都不一样。我在封装层做了一件事把精确求位拆成两步粗定位用低金字塔层数快速找精定位在上层做亚像素细化。这样既能保证速度又能把角度输出稳定下来。public VisionResult FindShapeModel(HObject image, ShapeModelParam param) { using var hoShape new HObject(); using var hoWindow new HObject(); HOperatorSet.FindShapeModel( image, _modelId, param.AngleStart, param.AngleExtent, 0.5, // MinScore第一遍粗找 1, // NumMatches 0.5, // MaxOverlap least_squares, 0, // SubPixel粗定位不放亚像素 0.8, out hoShape, out hoWindow); double row, col, angle, score; HOperatorSet.GetShapeModelContour(out var contour, _modelId, 1); // 若分数不达最终阈值再提高需求做一次精定位 HOperatorSet.TupleSelect(hoShape, 0, out HTuple rowT); HOperatorSet.TupleSelect(hoShape, 1, out HTuple colT); HOperatorSet.TupleSelect(hoShape, 2, out HTuple angleT); HOperatorSet.TupleSelect(hoShape, 3, out HTuple scoreT); row rowT.D; col colT.D; angle angleT.D; score scoreT.D; return new VisionResult(row, col, angle, score); }这个封装看起来简单实际上把 Halcon 特有的 HTuple 坑吃了一遍find_shape_model 返回的是一个元组行、列、角度、分数全塞在同一个 HTuple 里用下标取出来是 HTuple 类型直接转 double 没问题但如果视觉结果为空取元素会抛异常。所以每个工具类都在入口做了空结果检查返回一个 Score 为 0 的默认结果而不是让异常炸到流程层。2.3 授权与运行环境的部署细节Halcon 集成里另一件不写文档但早晚要吃大亏的事是运行时授权。开发机上有完整 license一切正常部署到现场工控机如果没装对应 runtime 或 license 不对程序启动就报错界面都出不来。v2.1 的安装包里把 Halcon Runtime 作为前置组件处理了启动时检测 license 文件是否存在、是否过期检测不过给出明确提示而不是让用户看一个笼统的异常。还有 HDevelop 导出的 C# 代码很多项目细节不能直接用HDevelop 里的图像路径是绝对路径导出到上位机必须改成由流程节点传入HDevelop 里的 variables 是一大串 HTuple在 C# 里必须重新组织成有意义的对象。我建议所有从 HDevelop 验证过的算子脚本统一在 C# 里重新封装成工具类不要直接粘贴导出代码。3. 拖拽式编程的落地流程节点怎么翻译成 PLC 动作3.1 节点模型一个 Node 基类撑起整张流程图拖拽式编程最核心的不是画布而是数据模型。我定义了一个 NodeBase 类所有流程节点继承它每个节点有输入连接点、输出连接点、参数列表和 ExecuteAsync 方法。流程图本质上是一个有向图每个节点持有一组出边引用。节点类型 v2.1 总共做了十几种启动节点、视觉定位、运动到位、PLC 写、PLC 等待输入、延时、条件分支、计数循环、消息弹窗、数据计算。每个节点打开右侧属性面板能改的参数不一样视觉节点填模板名称和匹配阈值运动节点填轴号和目标位置表达式PLC 写节点填寄存器地址和数值来源。public abstract class NodeBase { public string NodeId { get; set; } public string DisplayName { get; set; } public ObservableCollectionInputConnector Inputs { get; set; } public ObservableCollectionOutputConnector Outputs { get; set; } public Dictionarystring, object Params { get; set; } public abstract TaskNodeResult ExecuteAsync(FlowContext context); public virtual NodeBase Clone() { var clone (NodeBase) MemberwiseClone(); clone.Params new Dictionarystring, object(Params); clone.Inputs new ObservableCollectionInputConnector(); clone.Outputs new ObservableCollectionOutputConnector(); return clone; } }画布 UI 我自己写了一套轻量的 WPF 控件没有用第三方流程图库。因为第三方库的节点外观往往改不到我想要的工业风而且拖拽缩放行为在现场触摸屏上表现不稳定。自己画的好处是每个节点的引脚位置完全可控后面加新节点类型只需改一个模板。3.2 从画布到动作序列编译与预运行检查拖出来的图不能直接执行要经过编译。v2.1 的流程引擎拿到节点集合和边集合之后先做拓扑排序找出从入口节点可达的全部节点检测有没有循环依赖。流程图允许条件分支和循环所以在拓扑排序失败存在环时引擎会定位到产生环的两条边在界面上标红提示不允许启动运行。编译结果是一份有序的执行计划它不只是一个 List而是一棵带有分支条件的决策树。真正的执行器是一个基于栈的调度器遇到条件分支节点根据运行时变量决定走哪一条出边遇到循环节点维护循环计数。这套调度器和 PLC 的执行逻辑有很多相似之处但上位机的好处是能拿到所有变量的实时快照方便在生产记录里回放每一步当时的数据。执行计划还有一个离线预检阶段编译通过后把所有 PLC 写地址和读地址收集出来和当前连接的 PLC 寄存器表做一致性校验发现地址越界或地址冲突会直接提示。这一步花了我不少时间但价值非常大因为在现场拖流程时最怕的就是拖出一个写地址重复的节点导致两个动作互相覆盖。3.3 运行时的指令下发与状态回读流程执行器真正跑起来后与 PLC 的交互不是发一条指令就干等结果而是发出指令后进入异步等待状态事件来时恢复流程。以运动到位的视觉节点为例视觉定位完成结果写入变量区流程走入运动节点运动节点构造目标坐标写入 PLC然后把自己挂起在等待队列里。PLC 侧有一个状态字寄存器每完成一个动作就把对应动作号置位。上位机通过一个周期循环读取状态字发现和当前等待的动作号一致就唤醒对应节点继续执行后续逻辑。这样避免了一个很傻的同步等待死锁如果 PLC 运动报错没走到位上位机不能永远傻等要在超时时间内跳到异常分支。这里要特别提一下 UI 反馈的细节。拖拽流程在自动运行的时候执行中的节点要用高亮边框标记出来已完成的节点变绿跳过的节点变灰。操作员盯屏幕不需要读日志一眼就知道卡在哪一步。这一个体验细节让现场调试效率提升非常明显。4. 视觉坐标到 PLC 补偿换算关系算错一步全部定位都是歪的4.1 相机标定矩阵与像素坐标的转换视觉平台与 PLC 运动轴对接绕不开的是坐标换算。v2.1 用的方法是 2D 仿射变换加逐点标定补偿。首先做相机畸变标定用 Halcon 的标定板算子算出相机内参把畸变去掉然后做手眼标定建立像素坐标和机械坐标的 HomMat2D 矩阵。这个矩阵的含义很简单一个像素坐标 (row, col) 通过矩阵乘一个 3 乘 3 的变换得到一个机械坐标 (X, Y)。但要命的是Halcon 的坐标系约定是 row 从上往下增大col 从左往右增大而多数运动控制卡的机械坐标系是 X 向右、Y 向上两种约定如果没对齐换算出来的坐标会绕着一个中心旋转 90 度甚至镜像现场定位结果会整体拧掉。public PointF PixelToMachine(double row, double col) { // 内部缓存的 HomMat2D 由标定过程生成 HTuple rowMc new HTuple(row); HTuple colMc new HTuple(col); HTuple qx, qy; HOperatorSet.AffineTransPoint2d(new HTuple(_homMat2D), rowMc, colMc, out qx, out qy); return new PointF(qx.D, qy.D); }除了基础矩阵实际生产还要叠加一个关键补偿项植板轴的倾斜量。如果相机安装在植板执行轴的旁边而不是正中间轴在不同 X 位置时Y 方向会有一个线性偏移。这个用一次线性回归做补偿在标定矩阵之外再维护一张 CompOffset 表按 X 坐标查补偿值。4.2 通讯协议选型Modbus TCP 为主兼顾 SocketPLC 通讯这一块我先定了一个原则凡是数据量小、周期要求不高10 到 50 毫秒的信号一律走 Modbus TCP凡是位置数据、图像判定结果这类需要批量传输的结构化数据走 TCP 透传自定义报文。Modbus TCP 的好处是现场调试工具太多了随便一个 Modbus 测试软件就能监控寄存器PLC 工程师上手快不用我解释协议细节。地址规划做成了一张常量表注释写清楚每一个寄存器的含义和单位地址名称读写类型说明0x0001启动指令写Word1 启动0 停止0x0010皮带速度写Word单位 mm/s0x0020植板 X 轴目标写Float双字低字在前0x002A状态字读Word当前完成动作号0x0080报警代码读Word非 0 时流程进入异常分支值得提醒的是 Float 的字节序。用 Modbus TCP 写浮点数很多 PLC 默认是大端双字而 C# 的 BitConverter 默认是小端直接拼接会整个错位。我在封装层专门做了字节序转换并且留了一个可配置开关方便对接不同牌子的 PLC。4.3 补偿值落地的边界保护坐标补偿值写完 PLC不代表万事大吉。现场有一种常见情况视觉误检定位偏差很大比如模板匹配到了错误的位置算出的坐标离正常范围差了十万八千里。如果上位机把这个值直接写进 PLC运动轴会冲过去撞机。v2.1 在坐标写出前加了三重保护范围拦截、速度拦截、连续一致性检查。范围拦截是在流程节点参数里配置每个轴的最大行程区域超出就直接判定为视觉失败走重拍或报警分支速度拦截是计算相邻两拍目标点的距离估算运动速度超过轴的物理极限就拦截一致性检查是把当前视觉结果和上一拍结果对比如果差值超过预设阈值且不是产品规格切换导致的判定为可疑结果。这三重保护在试产阶段帮我拦下至少四五次因为模板误配引起的撞机隐患。调试期视觉参数不稳定新模板刚创建时角度范围很容易配得太宽松误检率直线上升。有边界保护在即使误检设备也只会停在原位报警不会做危险动作。5. 现场联调实测三个印象最深的排错过程5.1 光照变化导致的模板匹配闪断第一次现场联调视觉工位在下午三点左右开始频繁报定位失败。上午好好的下午陆陆续续出现失败持续几分钟又恢复。排查半天发现厂房东侧有一扇卷帘门下午阳光会斜射到视觉工位防护罩的透明观察窗上在基板表面形成一块渐变的漫反射亮斑模板匹配分数掉到阈值以下。这个问题解决起来反而不难一是调整了防护罩方向贴了遮光膜二是在 Halcon 采集参数里打开了相机的自动曝光和增益上限控制三是视觉节点里把图像预处理做成可选匹配之前先做一次均值滤波降低局部高光干扰。经这样处理之后模板匹配稳定性大幅提升后续也没有再被光照突然变化打崩。5.2 拖拽流程的循环依赖死锁有次客户需求要加一个定位失败自动重试最多三次的分支。我按直观思路在画布里画了视觉失败节点连回视觉节点本身形成一个循环。结果流程编译阶段直接报存在循环依赖怎么都保存不了。问题出在引擎的拓扑检测只认图结构不区分正常循环和异常环。后来我把循环语义单独抽成一个固定节点类型LoopN用户不直接画回边而是配置 LoopN 的循环次数内部自动维护回跳逻辑。这样画布上永远不会出现裸的环形连接编译逻辑也简单了顺带解决了流程可视化时候环结构显示错乱的问题。这也是拖拽式编辑器的一个设计经验不要让用户自由连回边把所有循环语义都收敛到特殊节点里。5.3 PLC 指令堆积导致的动作重叠上线跑了一整天之后现场发现植板动作偶发性地抢跑就是上一次植板还没彻底回位下个周期的植板信号就已经到了。查下来是通讯写入时序的坑上位机把 PLC 目标地址连续写了多个值PLC 在扫描周期内同时读取到了新目标而上一次动作还没完成状态字还没来得及更新上位机逻辑误以为已经空闲。修复方式是引入击穿指令握手每一条动作指令都有唯一序列号PLC 执行完才把序列号回写到状态寄存器。上位机判断动作完成不再看位置到位信号而是比较返回的序列号和发出的序列号是否一致。这个改动虽然小但直接消除了指令堆积引起的动作重叠安全性和节奏稳定性都提高了。6. 关于 v2.1 设计和部署的一些个人体会整套 v2.1 从立项到基本稳定前后用了三个多月其中一半时间花在现场联调另一半时间花在把以前靠开发记忆才能解决的流程细节变成可视化配置。回头看最值得的位置投入不是 Halcon 算子怎么写也不是 PLC 通讯怎么调通而是把每个节点的边界条件想清楚了视觉失败怎么办、PLC 超时怎么办、补偿值越界怎么办这些分支在拖拽画布里都成为透明的逻辑操作员能看见也能自己调整。最后分享一个部署上的小习惯给每台设备的上位机配置文件里加了流程版本号字段每次换型保存的流程文件都会把版本号写进生产记录。设备出问题追溯的时候先比对工艺是否用错版本再排查机械和电气能省掉大量无效沟通。这个习惯毫无技术含量但在多班组生产的工厂里价值比任何算法优化都大。