PLC信号触发视觉流程：Vision Master自动化集成实战解析

前几天在产线调试一套视觉检测工位PLC那边反复反馈“信号已经发出去了视觉就是不触发”。我跑过去一看问题出在一个特别基础但又特别容易被忽略的环节PLC输出的DO触发脉冲只有不到20毫秒而Vision Master端的输入滤波默认设了30毫秒信号直接被当成毛刺滤掉了。这种问题在“PLC信号到视觉流程”的自动化触发集成里太典型了也是很多刚接触Vision Master的人首先会撞上的坑。这个项目标题叫“Vision Master——从PLC信号到视觉流程的自动化触发实战”本质上讲的就是工业现场最常见的一条链路PLC给视觉系统一个信号视觉系统拍图、检测、把结果送回去PLC再决定工件放行还是剔除。整条链路里Vision Master负责视觉流程的执行PLC负责逻辑调度两者之间的信号交互决定了这套系统能不能稳定跑起来。这篇文章我会把这条链路从方案选型、通信设计、实操搭建到故障排查完整拆一遍适合正在做视觉集成、或者是刚把Vision Master引入现有产线的工程师参考。1. 触发链路先想清楚PLC和Vision Master各负责什么1.1 三种激活视觉的方式怎么选先理清楚一个概念“触发”不等于“拍照”。在PLC和视觉系统的集成里触发动作可以是通知视觉开始采集也可以是通知视觉切换程序、复位状态、上报结果。按照信号传输的物理形式常见有三种激活方式。第一种是硬件IO触发。PLC的输出模块直接接到相机的Line Trigger输入口或者接到Vision Master控制器的IO输入端子。这种方式实时性最好信号从PLC输出到相机曝光启动的延迟可以控制在微秒级适合高速飞拍、线扫相机这类对时间精度要求极高的场景。但它的缺点是信息量几乎为零一个电平信号只能表达“拍了”或者“没拍”PLC想知道检测结果还得通过另外的IO点读回来。第二种是通信触发。PLC通过以太网、串口或者现场总线向Vision Master发送一段指令比如“TRIGGER:01”或者Modbus寄存器写入一个值。Vision Master收到指令后触发流程执行。通信触发的实时性比硬触发差一些以太网轮询周期、系统调度延迟都会叠加进去但它的优点是信息量丰富一次通信可以携带产品型号、批次号、工位编号等多种信息而且不需要额外接线。第三种是软触发也就是视觉系统内部定时、或者由上位机软件按钮触发。这种方式一般只用于调试阶段产线运行时基本不会用。我在实际项目里一般遵循一个原则检测节拍要求小于100毫秒、而且工位固定不变的优先硬触发节拍在几百毫秒以上、或者一条产线要频繁切换产品型号的优先通信触发。用通信触发还有一个额外好处就是触发的同时能把产品信息带过来后续做数据追溯会省很多事。1.2 为什么这条链路用Vision Master更省事市面上做视觉检测的框架不少OpenCV、Halcon、Vision Master各有各的适用场景。很多人上来就会问“到底选哪个”我的答案取决于两件事你要写多少代码以及你要不要面对产线维护的人。OpenCV是代码级的灵活度天花板最高但所有东西都得自己搭界面自己做、标定自己做、接口自己做。如果你的项目是纯科研预研、或者团队里有专职算法工程师长期维护用OpenCV没问题。但产线不一样今天电气工程师要改个信号逻辑明天工艺员要调个检测参数OpenCV那种“改个阈值都要改代码重新编译”的方式在实际量产维护里真的会把人逼疯。Halcon是算法验证的利器算子丰富、文档详尽但授权费用不低而且它默认给的是一个底层算法库界面、流程管理、通信交互仍然需要二次开发。很多用Halcon的团队实际上是在Halcon基础上又包了一层厚厚的C#或者C外壳把流程编排、结果展示、通信协议全部自己做一遍。Vision Master走的是流程化、低代码的路线。它把相机采集、图像预处理、定位、测量、读码、OCR这些能力做成了可视化模块拖拽连线就能搭出一条检测流程。更关键的是它自带通信组件、逻辑脚本、变量管理这些偏“设备集成”的能力正好补上了视觉算法平台在自动化协同上的短板。你看它的定位就知道它要解决的不只是“图能不能检出来”而是“视觉怎么装进产线、怎么被PLC调度”。我自己在做的几个项目里从搭建流程到联调PLC大部分工作从写算法代码变成了配置逻辑和调试信号效率完全不是一个量级。2. PLC信号怎么进视觉流程触发机制与通信设计2.1 硬触发与通信触发本质差异在哪很多人觉得硬触发就是把PLC的输出点接到视觉设备的输入点上连上就能用其实里面全是细节。先说电平匹配。PLC的晶体管输出有NPN和PNP之分NPN输出低电平有效PNP输出高电平有效。而Vision Master控制器或者相机的IO输入普遍是光耦隔离输入内部有一个发光二极管你要根据是“灌电流”还是“拉电流”来接。接反了不会烧设备但信号永远触发不了这是排查问题时的第一嫌疑。再说滤波时间。视觉控制器为了保证抗干扰输入端口通常会做数字滤波滤波时间从几十微秒到几十毫秒可配置。就像开头的例子PLC的触发脉冲只有20毫秒如果滤波时间设得比它还长信号就没了。所以在做硬触发时要先确认PLC输出脉冲能持续多久再反推Visual端的滤波参数通常的做法是让脉冲宽度至少是滤波时间的3倍以上。涉及线扫相机的时候还要注意线扫相机一般用差分信号做行触发比如RS-422或者LVDS电平抗干扰能力强适合高速运动场景。而普通面阵相机多用光耦隔离的单端输入。如果你在项目里发现硬触发不稳定、有漏触发排查线缆屏蔽、接地、差分信号完整性比换相机和换PLC更实际。通信触发就完全是另一套逻辑了它不依赖电平但依赖协议和时序。实时性上限取决于通信周期比如PLC的扫描周期、以太网的调度周期、视觉系统的指令解析周期三者的最大值就是理论触发延迟。这个延迟在大多数工位上是可接受的但如果你要做的是高速飞拍比如产品以每秒两米的速度通过相机视野通信触发的抖动会导致产品在画面里的位置不确定给后续图像处理带来额外负担那就必须用硬触发加外部编码器锁定位置。2.2 通信协议怎么约定才不会扯皮通信触发看上去就是“发一条指令过去”但真到联调现场最耗时的往往不是图像算法而是双方对指令格式的理解不一致。我在第一个Vision Master项目里跟PLC工程师为了“到底发几个字节、要不要换行符、大小写是否敏感”反复折腾了一下午。后来我总结出一套通信协议设计规范能省掉大部分扯皮时间。指令格式必须包含三个要素触发标志、数据长度、校验方式。不管用TCP还是串口指令要尽量短、固定格式、无歧义。比如我常用的下行指令格式是这样约定的触发指令T#01其中T表示触发01表示工位号以#作为分隔符固定3字节。复位指令R#01用于视觉系统重新就绪。查询指令Q#01PLC主动查询视觉当前状态。上行结果回报格式则需要把检测结论量化出来结果指令R#01#OK#123.45依次表示工位号、检测结论、测量值。状态指令S#01#BUSY视觉正在检测中。表格整理一下就是这样的对应关系指令方向指令示例含义典型使用场景PLC→视觉T#01工位1触发拍照检测到位信号触发PLC→视觉R#01工位1复位故障恢复后复位PLC→视觉Q#01查询视觉状态节拍冗余时巡检视觉→PLCR#01#OK#12.34工位1检测OK测量值12.34检测结果反馈视觉→PLCR#01#NG#-1工位1检测NG检测结果反馈关键原则是“一次只做一件事”不要在一条指令里既触发又查询又复位。通信协议设计得足够简单清晰后续无论是接MES系统还是加其他设备都会有很好的兼容性。握手与超时机制也是不能省的。PLC发了触发指令之后必须处理两种异常视觉没收到、或者视觉收到了但结果没回来。我会在PLC侧设计一个“等待结果超时”的定时器比如设定800毫秒超时就把本次触发当作异常上报而不是无限等下去。这样产线运行中即使出现偶发通信故障也不会导致整个工位“挂死”。2.3 全局脚本Vision Master里获取和回写变量的关键Vision Master的流程搭建只是基础能力真正让它跟PLC形成自动化闭环的是变量和全局脚本机制。你可以把视觉流程里的每一个工具定位工具、测量工具、读码工具的输出结果理解成一堆“变量”比如圆直径、边缘距离、条码内容、OK/NG标志。这些变量默认只在流程内部流转但如果要跟外部设备交互就需要把它们映射到全局变量空间。Vision Master的全局变量分为系统内置变量和用户自定义变量用户可以在流程的任意节点插入全局脚本用类C#的语法读写这些变量。下面这段代码是我在实际项目里用过的写法思路主要功能是在流程跑完后把视觉测量结果和判定结论读出来格式化后准备发送给PLC。// 示例在流程结束节点读取变量并整理结果 // 不同版本的API命名可能有差异请以SDK文档为准 string strOKNG (string)GetGlobalVariable(Global_OKNG); double dValue (double)GetGlobalVariable(Global_Width); string sendMessage $R#01#{strOKNG}#{dValue:F3}; // 调用通信模块发送接口 SendToPLC(sendMessage);反过来PLC发来的指令也需要通过全局脚本写入变量再参与流程逻辑。比如收到T#01之后脚本可以解析出工位号把工位号写入一个全局变量然后触发流程节点执行。这样同一个视觉程序就能在多工位共用工位编号作为变量跟随每一帧图像流转后续做数据追溯也不会混淆。新手容易犯的错误是把所有逻辑都堆在一个全局脚本里。全局脚本本身也是有执行时间和资源开销的脚本写得太大太复杂轻则影响检测节拍重则在图像处理最耗时的时候抢CPU资源导致丢帧。我的习惯是“节点内小脚本、关键节点大逻辑”同时把耗时的数据格式化、日志写入等操作放到流程结束后异步执行尽量不影响下一帧图像的采集。3. 从零搭一套自动化触发项目完整实操参考3.1 我的调试环境和网络拓扑为了把这个过程讲具体我拿最近做的一个真实需求举例一个流水线上的产品到位检测工位产品被传输带送到视觉下方后PLC要触发视觉拍照检测产品有无、测量装配尺寸、输出OK/NGNG品由后段吹气阀剔除。硬件环境视觉部分Vision Master工控机配一台500万像素面阵GigE相机镜头视场覆盖整个产品区域。PLC部分西门子S7-1200系列自带以太网口输出控制气缸和吹气阀。通信方式以太网通信触发PLC作为TCP客户端主动连接Vision Master工控机。网络拓扑就是一个最简单的星型结构PLC和工控机都接到产线交换机上PLC设定固定IP比如192.168.1.10工控机设定固定IP比如192.168.1.120两个设备在一个网段内。这里强调一下工控机必须用固定IP不能用DHCP否则PLC重启或者交换机重新分配IP之后通信就断了。3.2 PLC侧的关键编程要点PLC侧的程序逻辑不复杂但有几个点值得注意。核心流程是产品到位传感器亮起→气缸夹紧→延时200毫秒稳定→发送触发指令给视觉→等待视觉返回结果→根据结果决定放行或剔除→复位等待下一个工件。发送触发指令的程序我用的是西门子的开放式通信指令Open Communication在TIA Portal里调用T-block系列的通信指令块建立TCP连接后用TSEND发送一帧数据。梯形图或者STL的写法大致逻辑如下// 伪代码描述实际指令请按TIA Portal向导填充 Network 1: 产品到位 LD I0.0 // 到位传感器 AN M20.0 // 忙碌标志 S M10.0 // 触发请求 Network 2: 发送触发指令 LD M10.0 CALL TCON, ... // 建立连接目标IP 192.168.1.120端口4999 // 发送内容为 T#01 CALL TSEND, ... S M20.0 // 置位忙碌防止重复触发 R M10.0 Network 3: 接收结果 LD M20.0 CALL TRCV, ... // 收到 R#01#OK#... 或 R#01#NG#... // 置位M30.0表示OK或M30.1表示NG Network 4: 超时处理 LD M20.0 TON T1, PT:T#800MS // 800ms未收到结果则超时报警这里有一个非常容易踩的坑TCP连接不能反复建立和断开。PLC扫描周期很快如果每个扫描周期都去执行TCON建连会把通信资源耗光导致连接不稳定。正确的做法是把连接建立放到初始化段只建一次后续只做TSEND和TRCV。我见过不少项目连不上查到最后都是这个原因。3.3 Vision Master端流程和全局脚本实现Vision Master这边的核心动作有两个一是接收并解析PLC的触发指令二是流程执行完把结果发回去。接收指令这步我用的是Vision Master通信组件里的TCP服务器功能监听固定端口4999。加一个全局脚本作为“指令分发器”收到数据后解析出指令类型触发对应流程。// 示例指令接收与分发示意写法 string msg GetReceivedMessage(); if (msg.StartsWith(T#)) // 触发指令 { SetGlobalVariable(Global_Trigger, true); RunFlow(Flow_Detect); // 调用检测流程 } else if (msg.StartsWith(R#)) // 复位指令 { SetGlobalVariable(Global_Trigger, false); }视觉流程本身我按先后顺序挂上线图像采集→模板定位→边缘测量→逻辑判定。模板定位是保证测量的基准边缘测量输出装配宽度值逻辑判定负责判断测量值是否在公差范围内最后把OK/NG写到全局变量里。流程跑完之后在流程结束节点挂一个全局脚本把结果拼成协议格式发回PLC。也就是前面提到的代码逻辑从全局变量取出OKNG字符串和测量值格式化后调用Socket发送接口。// 示例结果回报示意写法 string okng (string)GetGlobalVariable(Global_OKNG); double width (double)GetGlobalVariable(Global_Width); string resultMsg $R#01#{okng}#{width:F3}; Send(0, resultMsg); // 通过已建立的连接发送这样一套下来PLC和Vision Master之间的闭环就通了。视觉流程的触发、执行、结果返回完全由信号驱动不需要人工干预。3.4 联调顺序先通再稳后准联调时不要一上来就模拟全流程我习惯按“先通、再稳、后准”三步走。第一步“先通”先把通信链路打通。用PC上的串口调试助手模拟PLC直接给工控机发一条T#01看Vision Master能不能收到、能不能触发流程、流程能不能跑完。这一步不关心检测精度只验证数据通路是不是通的。第二步“再稳”连续发几百次触发指令观察有没有漏触发、重复触发、指令粘包。稳定性测试建议放到恶劣条件下做比如让PLC和视觉同时满载运行测试各个负载叠加时的通信表现。如果发现偶尔丢指令优先检查连接方式是长连接还是短连接、接收缓冲区是否溢出、脚本执行是否超过通信超时时间。第三步“后准”在通信稳定的基础上把PLC真正接入用真实的节拍跑完整的“触发-检测-反馈-剔除”循环。这时候才去调图像算法精度、测量公差范围坐标系标定这些东西不要在前面链路还没通的时候就去调图像。这个顺序帮我省过非常多时间。很多时候产线上一堆问题看起来像是“视觉没检准”实际上底层是“PLC触发的时机不对”工件位置还没稳定就拍照再好的算法也白搭。先把链路稳住了算法问题才能暴露真面目。4. 高频故障与排查手法实录4.1 触发信号送了视觉不动作这是占比最高的故障遇到“PLC发了信号但视觉没反应”的反馈我的排查顺序是固定的。先查通信层用调试助手在工控机上监听端口看PLC到底有没有把指令发过来。这一步能快速区分问题出在PLC侧还是视觉侧。如果监听不到任何数据大概率是IP、端口、网线或者PLC程序的问题。监听得到数据但视觉不动作才往下查视觉层。再查协议层监听得到的数据是不是正确格式。很多时候PLC发过来的指令末尾带着回车换行符或者大小写不一致导致脚本解析失败。我在脚本里做解析时通常会先做Trim去空白再匹配关键字容忍一定程度的格式差异。最后查变量层确认触发指令有没有正确写入全局变量。有一个隐蔽的问题Vision Master的流程执行是有节拍差异的如果PLC发的触发速度超过视觉处理速度后面的触发指令可能会被丢弃。这种情况下应该在PLC侧做个“上次结果回来了才发下一次”的互锁而不是无脑发。4.2 偶发通信中断、指令粘包乱序TCP通信有一个特性叫“粘包”就是多条指令被操作系统合并成一包发送接收方如果按包去读可能一次读到两条指令。另外TCP是流式协议没有天然的消息边界如果通信双方没有约定消息结束标志就很容易出现半包、粘包。解决粘包的办法有几个一是每条指令末尾加固定的结束符比如换行符\n接收方读到结束符才算一条完整指令二是在指令前加固定长度字段接收方先读长度再读内容三是固定每条指令的字节长度比如统一4字节。实际操作中固定字节长度最简单稳定缺点是灵活性差。我一般用结束符方式配合超长包保护解析时如果一帧数据里包含多条指令按结束符拆开逐条处理。偶发中断的排查重点看连接是否被异常断了、接收线程是否死锁、TCP保活报文有没有设置。PLC按长连接设计时建议在网络参数里开启TCP KeepAlive并用一个周期性的心跳指令来维持连接。设备断电恢复后PLC要能自动重连这个逻辑在PLC侧初始化段里要写清楚。4.3 结果错位一次来两个工件怎么办视觉检测最怕“结果串位”也就是这次拍的是A产品返回的确是B产品的检测结果。这种问题在节拍快、传输带连续送料的情况下非常容易出现。根源在于触发指令、图像采集、结果返回三者之间没有建立起“一一对应”的关系。PLC发来两条触发指令视觉可能处理完第一条后还没来得及回结果就收到了第二条如果发送缓存的逻辑没写好两条结果就可能弄混。我的解决办法是在协议里加入序列号。每条触发指令带上一个自增的编号比如T#01#0001视觉流程执行时把这个编号当作变量随图像结果一起流转结果返回时原样带回PLC侧就能根据序列号精确匹配。这相当于给每一次检测都挂了一张“身份证”彻底杜绝串位。4.4 多相机同时触发时的资源竞争一台工控机接多相机的项目里另一个常见问题是资源竞争。两个相机的触发信号同时到达Vision Master可能会在同一时间点发起两路图像采集导致CPU占用率飙升、图像传输带宽抢占最终表现为某一相机的取流超时。我的做法是给多相机做触发错峰。如果触发源是同一个PLC就让PLC在时序上做前后偏移比如第一个相机触发后延时20毫秒再触发第二个。如果PLC无法做偏移就在Vision Master侧加逻辑互斥同一时间只允许一个流程占用采集资源另一个流程挂起进入等待队列。多相机系统还有一个容易被忽略的点就是GigE相机的网卡带宽建议一个千兆网口最多挂两台500万像素相机超过这个数量要考虑万兆网卡或者改走相机自带缓存策略。说到底视觉系统接入PLC信号做自动化触发本质上解决的是一场“信号与系统”的协同问题PL侧和视觉侧的时序配合、通信设计、异常处理每一层都直接决定产线能不能稳定跑。我在实际项目里最深的一个体会是联调现场不要把问题全部归到“视觉算法不准”或者“PLC程序有问题”而是要从触发链路的最上游开始一层层往下查先保证信号链路可靠再谈图像效果。最后再分享一个小技巧在所有通信联调之前先花半天时间把通信协议文档写清楚发给现场的PLC工程师和调试工程师各一份格式、时序、异常处理全部落到纸面上。看似多花了时间实际能省下后面几天的扯皮这个投资永远不亏。