用流程图开发火花塞瑕疵检测:从采集到输出的工业视觉实战 📅 发布时间:2026/9/1 7:27:44 👁 浏览次数: 开头先让火星塞检测这个场景立起来再谈流程图这件事有多反直觉。火星塞也就是我们常说的火花塞在发动机里工作环境极其苛刻。陶瓷绝缘体要扛住高压中心电极和侧电极的间隙要精确到毫米以下一个微小裂纹、崩瓷或电极歪斜都可能让整个点火系统出问题。工厂里最早的检测方式是人工拿放大镜一个一个看。后来相机和视觉软件进来了但问题并没有消失只是从眼睛累变成了软件开发慢。项目负责人说两周后要上线但产线还在等方案这时候很多人会站在一道选择题前是老老实实写一套 C# 或 C 视觉检测程序还是找一个更快交付的工具。我第一次听到用流程图开发检测软件这个说法时第一反应是怀疑。Matrox Design Assistant 这类图形化视觉开发环境把图像采集、视觉工具、结果输出画成一张可执行的流程图听起来好像把生产检测变成了搭积木。后来在类似任务里试过之后我的判断变得很清楚用流程图做火星塞瑕疵检测不仅可行而且对很多产线项目来说可能是比写代码更合理的工程路径。但它真正解决的问题不是不会写代码也能做算法而是把视觉系统的开发、调试、交接和维护成本降下来。这篇文章就围绕火星塞瑕疵检测这条线把这类工具的底层逻辑、最小实现、适用边界和落地细节讲透。1. 先搞清楚流程图开发检测软件到底改变了什么1.1 传统视觉开发为什么让人头疼工业视觉项目如果走传统路线通常是一套 C/C# 程序加一个视觉库自己处理相机采集、图像预处理、算法调用、结果显示、数据保存、IO 通信。表面上看核心工作是算法真正耗时间的却往往是工程部分。相机驱动要初始化图像回调要处理界面要能显示实时画面参数要能保存PLC 信号要能触发不良品要能计数日志要能追溯。这些功能没有一样是算法但每一行代码都可能出问题。更麻烦的是现场调试。算法参数在实验室里看起来没问题一放到产线光源反射变了、产品位置偏了、来料批次不同了原来的阈值立刻不灵。工程师改一次参数要改代码、重新编译、重新部署快则几分钟慢则一二十分钟。如果现场没有专职软件工程师整个项目就可能卡在改一个阈值这种小事上。1.2 Design Assistant 的流程图不是画图而是程序结构很多人一看流程图三个字会联想到 drawio、Visio 或者 PPT 里那种示意图以为就是把检测思路画出来给人看。这是最大的误解。Matrox Design Assistant 这类流程图本质上是一套可执行的程序结构。每个方块不是一个注释而是一个功能模块每条连线不是箭头装饰而是数据流和控制流。图像从采集模块出来进入定位模块定位结果再传给检测区域模块区域结果经过判定模块最后输出到 IO 或通信模块。流程图画完程序就已经写完了。可以把它理解成这样传统代码里的一次函数调用、一个 if 判断、一个循环到了流程图里就是一个节点或一条分支。流程图的执行引擎会按照连接关系从上到下、从左到右地运行。这套东西看起来不像编程但它的底层逻辑和编程完全一致有变量传递有条件分支有循环等待有状态保存。它和用流程图说明反向传播算法原理也不是一回事。算法示意图是为了让人理解而 Design Assistant 的流程图是直接在工厂现场运行的检测程序。一张图既是设计文档也是可执行文件。1.3 它真正解决的问题是可现场迭代除了把开发方式从文字变成图形这类方案更重要的价值其实藏在项目中期和后期。产线视觉项目有几个确定性相机角度一定会被碰歪光源亮度一定会衰减产品型号一定会增加检测标准一定会调整。所以一套检测软件的长期竞争力不只是它第一次跑通的准确率而是每次遇到变化时改起来要多久、谁去改、怎么保证改完不乱。流程图方案的优势就在这里。现场人员打开工程文件找到对应节点把定位模型的搜索范围拉大一点把缺陷面积阈值从 50 改成 80保存重新运行几十秒就能完成一次调整。不需要重新编译不需要担心某个变量忘了声明流程之间的数据关系在图上看得一清二楚。但这句话也要说清楚它让现场迭代变得更容易不意味着完全没有门槛。你还是要理解图像处理里面的基本概念比如阈值、边缘、区域、定位、坐标变换。如果你连先定位再检测这个逻辑都不熟悉流程图也救不了你。2. 用火星塞瑕疵检测走一遍最小流程2.1 火星塞检测任务的难点在哪里火星塞属于典型的复杂机加工件材质多结构多反光强。需要检测的部位至少包括陶瓷绝缘体有没有裂纹、崩瓷、针孔、污染中心电极有没有缺失、歪斜、长度不对侧电极有没有偏移、断裂、贴合度不足螺纹部分有没有损伤金属壳体有没有变形或脏污。每一种缺陷对打光方式、检测工具和判定逻辑的要求都不一样。而且产线上的产品位置不会完全一致可能左右偏几个像素可能旋转一两度。如果你直接把检测区域写成固定坐标轻则检测区域框偏重则把螺纹区域的阴影当成了缺陷产生大量误检。所以火星塞检测不是一个放上去就能跑的任务先做定位是必要的。2.2 最小流程图像采集、定位、检测、判定、输出用流程图方式搭建火星塞检测第一步不是去考虑缺陷识别而是建立一条完整的链路。常见的最小流程是这样的[相机触发] - [图像采集] - [定位参考] - [区域映射] - [缺陷检测] - [OK/NG 判定] - [结果输出]如果你的项目原本用传统视觉库逻辑大概长这样。我用伪代码说明只是为了帮你理解算法逻辑不是某种特定语言的官方写法# 伪代码仅用于理解处理顺序 image acquire_image() pose find_reference_pattern(image) # 找定位特征得到坐标和角度 roi_list map_detection_rois(pose) # 根据定位结果映射每个检测区域 for roi in roi_list: defects detect_defects(image, roi) # 做边缘、Blob 或灰度分析 if defects.max_area limit: result NG break send_result_to_plc(result)在 Design Assistant 这类流程图环境中每一个步骤会对应一个或几个模块图像采集模块负责等待相机触发并取图。先确保每次触发都能稳定采集一帧图像再去考虑后面怎么检测。定位模块用一个稳定的特征作为参考点比如陶瓷绝缘体的轮廓、金属壳体的转角。这一步会输出位置坐标和角度。区域映射模块预先画好一个标准位置下的检测区域。运行时根据定位结果把标准区域旋转、平移到当前图像的实际位置。缺陷检测模块在映射后的区域里使用边缘查找、Blob 分析或灰度统计找出疑似缺陷。判定模块把缺陷的面积、长度、数量与设定阈值做比较。结果输出模块把 OK/NG 信号发给 PLC、剔除机构或上位机。这里最值得提醒的是不要一开始就把所有流程连起来跑。先做采集和显示确认图像本身清晰再做定位确认参考特征在每张图上都能找到然后做单张静态样本检测最后才接输出和通信。注意不要一开始就把所有步骤都连起来。先把采集和显示打通再逐步加定位、检测和输出。流程图画得越完整中间环节越难排查。2.3 从单张验证到在线检测先加节拍和稳定性一套流程能在一张图片上跑出正确结果往往只意味着算法方向没问题离能上线还有距离。真正的产线场景里相机是飞拍还是停拍触发信号什么时候到产品有没有抖动检测模块处理完一帧需要多少毫秒PLC 多久来取一次结果这些都会影响系统是否稳定。流程图工具虽然简化了开发动作但没有消除这些工程问题。我建议先不要追求算法效果而是先测节拍。方法很简单让流程图连续运行 100 次记录每次采集到输出结果的耗时看有没有波动。如果偶尔一帧明显变慢往往不是检测算法太复杂而是相机重连、图像缓存或者通信超时这些环节出了问题。然后在产线实际工况下跑一段时间。注意观察连续运行半小时后误检率会不会上升。常见的现象是前 30 分钟很好之后开始误报多数情况不是算法漂了而是光源发热导致亮度变化或者产品表面粘上了油污。这些问题在流程图上很难直接看到要回到硬件端解决。3. 流程图里的关键选择哪些步骤直接用现成工具哪些要靠流程设计3.1 瑕疵检测不放第一步先定位再检测不少第一次接触视觉检测的人会把缺陷检测当成全部流程图上第一个节点就是找裂纹、找瑕疵。结果就是好产品在图片正中央时一切正常产品稍微偏一点就到处都是误报。原因是检测区域跟实际位置对不上。裂纹可能本来只有 0.3 毫米如果检测区域偏移 1 毫米螺纹边的阴影或陶瓷边缘的反光就会进到区域里被 Blob 分析算法当成了缺陷。所以在流程图上瑕疵检测前面必须先有一个定位节点。定位不是随便找一个点而是找一个在所有合格品和大部分不良品上都稳定存在、且不容易受缺陷干扰的特征。火星塞上通常可以选陶瓷绝缘体与金属壳体的交界处或者壳体本身的轮廓线。定位完成之后检测区域不要再手工逐个调整而是通过参考坐标映射过去。这样做有三层好处一是产品偏移时检测区域跟着走二是换型号时只需要换定位模型和区域定义三是调试时改一个参考点所有关联区域一起动不容易漏改。3.2 光源、镜头和图像质量决定了流程图能省多少事流程图工具能把开发流程串起来但它修不了图像本身的硬伤。火星塞是金属和陶瓷的组合反光严重。陶瓷表面如果用了不合适的入射光裂纹会被反光掩盖金属螺纹如果打光角度不对会产生大量高光点下一步不管用 Blob 还是边缘检测都会把高光误认成缺陷。所以画流程之前要先在硬件上把图像质量稳定下来。常规处理思路包括打光角度调整用低角度光突出陶瓷表面凹凸避免正面强反光。偏振片压制金属表面镜面反射。背光如果要检测外形轮廓和电极位置背光比前光更容易得到干净轮廓。固定相机位姿在产线上加装机械限位让产品进入视野时位置波动尽量小。如果图像上同样一个缺陷在白天和晚上、开机和热机时看起来差异很大那流程图上所有参数都会不稳定。这时候最该改的往往是光源和机械不是阈值。3.3 通信和结果输出PLC、IO、TCP/IP 的落点检测软件最终要跟产线其他设备配合。流程图方案通常会提供 IO 模块或通信模块用来对接 PLC、气缸、剔除机构、上位机数据库。在流程图里通信不只是一种发一个结果的行为它应该占一组节点。完整的输出流程至少包括等待触发收到传感器或 PLC 信号后才执行一次采集。检测完成把所有检测区域的判定结果汇总成一个 OK/NG。输出信号在指定的 IO 通道或通信报文里输出结果。等待复位等 PLC 确认收到结果后流程回到起点准备下一次触发。很多新手会漏掉等待复位这一步。如果输出之后直接回到等待触发而 PLC 还没处理完上一个结果下一轮触发一到结果就会被覆盖产线上就会出现明明检测到不良品却没有剔除的情况。这里不能只看流程图画得通不通还要和电气同事确认时序。比如相机曝光时间、PLC 扫描周期、剔除气缸动作时间三者之间是什么关系。流程图工具能帮你把逻辑画清楚但时序匹配还是要在现场联调。4. 真正容易踩坑的地方不是画图而是边界条件4.1 误检、漏检和阈值设置的权衡做瑕疵检测最麻烦的不是找不找得到缺陷而是阈值设多少。阈值设得严格细小的瓷面麻点、轻微反光、灰尘都会被判定为 NG结果产线上一大半好产品被当成不良品剔除浪费严重。阈值设得宽松又可能放过真正的裂纹漏检结果流向客户问题更大。所以调参不是对着流程图看效果而是建立两个样本集一个是已知 OK 的产品图像一个是已知 NG 的产品图像。每次调完参数都要把两批图像一起跑一遍统计 OK 产品的误检率和 NG 产品的漏检率。我建议把这两批图像保存成本地文件夹用流程图或配套工具批量回放。凡是改动过定位、阈值、区域范围都重新跑一遍。不要只拿刚采集的现场图像看效果因为现场图像容易带着当前环境和光源状态不能代表其他批次的差异。如果发现无论怎么调阈值都压不住误检先别继续调流程。回过去看图像质量、定位稳定性或打光方式。很多时候0.5 毫米的错位比阈值松紧更能解释误报。4.2 换型换产时流程图怎么维护火星塞的型号非常多不同型号的轮廓、尺寸、检测部位都不一样。如果每个型号都做一套独立流程图项目文件会爆炸现场也容易选错程序。更合理的做法是把流程图拆成两层一层是固定的处理逻辑另一层是可以切换的参数配方。每个型号对应一组参数包括定位模型文件、检测区域坐标、阈值范围、判定规则。运行时根据当前型号加载对应的配方再用同一套流程处理。表格可以帮助理解逻辑与参数分离项目同型号调试切换型号流程图结构不变不变定位模型重新训练可选切换模型文件检测区域固定随配方变化阈值现场微调随配方变化判定标准固定随配方变化这里最容易出的问题是换型后只改了检测区域忘了改定位模型或者反过来只换了模型忘了区域跟着变。流程图画得再好参数管理不清晰一样会在产线上搞出连锁反应。4.3 日志、版本和备份工厂环境的隐形需求工厂环境和实验室最大差别是设备要连续运行出了问题还要能追溯。所以在流程图上除了检测模块和通信模块还建议预留日志和图像保存逻辑。每检测一帧记录时间、产品型号、检测结果、各区域的具体数值对 NG 产品保存原始图像。这样事后如果客户投诉可以快速回看当时系统看到了什么。另一个容易被忽略的是参数备份。流程图画好了参数也调好了但某天有人不小心改了某个区域的位置保存后整个程序都变了。如果没有备份想恢复就只能重新调。我的习惯是每次改参数之前先保存一份当前项目文件或者至少把旧参数截图记录下来。项目正式交付前把最终版项目文件、相机配置文件、光源参数表、图纸和操作说明放在同一个目录里给现场留一份完整副本。参数改动前先保存一份旧项目文件或记录旧值。产线上最怕的不是效果差而是参数被改乱了以后无法恢复。5. 流程图方案适合谁不适合谁5.1 适合的场景项目制、现场交付、产线升级火星塞瑕疵检测这类任务如果属于典型的项目制交付周期短、需要现场反复调参、交付后由现场工程师维护那么流程图方案非常合适。原因很简单它把检测软件从一段难以解读的源代码变成了一张结构清晰、可现场修改、可逐步排查的流程图。新人接手时不需要从第一行代码开始看沿着连线往下走就能理解检测逻辑。如果你的产线设备型号经常换或者甲方希望自己也能改一些参数这种方案更值得优先考虑。现场问题通过远程指导就能调整不需要每次派一个软件工程师飞过去。5.2 不适合的场景算法预研、复杂定制、大规模数据迭代流程图方案不是万能的。如果你是做算法预研要试验多种深度学习网络结构、自定义损失函数、复杂的前后处理逻辑那它基本帮不上忙。这类工作的核心是算法创新和数据实验需要的是完全开放的程序设计环境。另外有些项目表面上写的是瑕疵检测实际上要做的是海量不良样本的数据采集、标注、训练和模型迭代。深度学习方案需要把数据流水线搭起来不断重训模型。这种项目里图形化流程适合把采集端串联起来检测核心还是得靠定制代码或专门的训练平台。流程图工具在表达复杂状态机时也会变得笨拙。比如一个系统要管理多相机、多工位、多型号交叉联动流程图上的连线和分支会非常多。虽然能做但复杂度高到一定程度后图形化表达的维护成本反而不如结构化代码。5.3 和其他方案对比SDK、通用视觉软件、视觉平台很多人会在三种路线里纠结自己用视觉 SDK 开发、用 Design Assistant 这类流程图平台、用简单配置的视觉软件。它们不是替代关系而是适用场景不同。对比维度传统视觉 SDK流程图视觉平台通用视觉软件开发方式写代码可视化连图界面配置调试速度较慢快最快灵活性高中低现场维护需要程序员现场可调简单操作复杂算法适合中等难长期扩展最容易定制受限但可控受限如果项目核心价值在于稳、快、易维护流程图平台通常是体验最好的平衡点。如果项目核心价值在于别人做不了的算法最终还是要回归传统编程。6. 落地建议先把在线稳定拆成五件事6.1 一个可复用的五步验证框架结合火星塞检测这类产线视觉项目我在实际落地时通常会按下面五个阶段推进。这个顺序可以复用到大多数流程图视觉任务上不一定完全踩火塞。第一步最小流程验证。用 5 到 10 张图片跑通采集—定位—检测—判定—输出的完整链路。这一步的目标不是准确率而是确认每个模块之间的数据能传通。第二步样本集验证。收集 30 到 50 张包含 OK 和 NG 的图片批量跑一遍记录误检、漏检和图像质量异常。把所有误检漏检的图片单独放一个文件夹作为后续调参的对照集。第三步通信联动验证。接上 PLC 或剔除机构按照真实时序跑一轮确认触发、检测、输出、复位每个环节的状态变化都正确。不要只看流程图模块有没有执行要观察 PLC 侧有没有收到信号。第四步节拍验证。按产线实际节拍连续运行 100 次以上记录单次耗时、异常报警、通信超时。如果速度跟不上优先优化定位搜索范围、检测区域大小或图像分辨率。第五步稳定性观察。连续运行半天到几天观察夜间光源变化、设备发热后成像漂移、来料批次差异是否导致误检。这一步最容易发现问题也最容易被项目计划忽略。如果按照这个顺序验证前面一步没有通过就不要急着进入下一步。很多项目出问题都是因为至少跳过了其中一步。6.2 现场调试最容易忽略的三件事回顾几个项目后我发现最容易让流程图方案翻车的不是流程图本身而是下面三件小事。第一硬件没固定就去调参数。相机哪怕被震动碰歪 0.5 毫米定位模块也许能扛住但检测区域和阈值都会受到影响。所以调试前先把相机、光源、限位机构固定好并做标记。第二改参数不留记录。很多人觉得先调调看不行再改回来但现场往往没有人记得原来的值是多少。正确做法是用表格记录每次改动的时间、参数名、旧值、新值、原因、对比结果。小项目也一样。第三不在现场观察一个完整轮班。复杂检测项目在白天看起来都很好到了晚上灯管频闪、太阳光从窗户射入、车间湿度变化误检率就可能上升。所以至少要留出覆盖不同时段的观察时间让系统在真实环境下暴露问题。6.3 回到主判断流程图是一种工程化路径不是算法捷径现在可以回答开头那个问题了。用流程图能不能开发出用于火星塞瑕疵检测的软件能。它不仅能在短周期内把检测流程跑起来还能让现场维护成本明显下降。但一定要明确它的位置这类工具改变的是工程化路径不是底层算法能力。一个缺陷能不能被稳定检测出来仍然取决于图像采集质量、定位逻辑、检测工具选择和阈值策略。流程图只是把这些环节更高效地组织起来让人更容易理解、调整和交接。如果你正准备进入工业视觉领域或者要做一条产线升级我建议先别急着纠结要不要写代码。先拿流程图把采集—定位—检测—输出这条主线画通再用小样本集验证效果你会在很短时间里理解一个视觉项目的完整结构。这个认知比学会某个工具本身更有价值。