前言当“深度学习”撞上“实时控制”在3C电子和汽车零部件产线上“AI视觉检测”早已不是新鲜词。但做过现场的工程师都清楚实验室里99%的识别率到了产线上可能连90%的稳定剔除都做不到。问题往往不在模型本身而在系统联动。AI推理耗时波动、PLC通讯延迟、编码器相位漂移、剔除机构响应滞后……任何一个环节的“不确定性”叠加都会导致漏剔或误剔。最近交付的一个新能源电池壳体外观检项目采用汇川H5U PLC C#上位机集成TensorRT推理 高速相机实现了200ms节拍下的稳定缺陷剔除。本文不讲模型训练只聚焦上位机如何作为“中枢”协调AI与PLC把不确定的AI结果变成确定性的物理动作。一、 系统架构为什么上位机必须是“调度核心”很多方案把AI推理放在工控机结果通过Modbus传给PLCPLC再根据IO信号触发剔除。这种“两段式”架构在低速场景没问题但在200ms以内的高节拍下致命缺陷暴露无遗AI推理耗时抖动30~80ms导致结果到达PLC的时间不确定Modbus轮询周期通常50~100ms进一步放大延迟PLC无法精确关联“哪个产品对应哪次推理结果”我们的解法是上位机承担“时空对齐”职责PLC只负责“精准执行”。GigE触发采集TensorRT推理编码器位置产品到位信号自定义TCP: 缺陷类型剔除相位角EtherCAT伺服IO高速相机C#上位机汇川H5U PLC高速剔除机构良品/不良品计数传感器 核心设计原则AI给出的是“这张图有没有缺陷”而上位机要回答的是“这个缺陷对应的产品将在编码器走到哪个位置时被剔除”。前者是图像空间后者是物理时空转换逻辑必须在上位机完成。二、 关键技术一基于编码器的“产品-图像”绑定这是整个联动系统的基石。相机拍照时刻与PLC记录的产品到位时刻必须精确关联。时序同步机制我们摒弃了“相机IO触发PLC记录”的传统方式改用编码器位置戳相机由PLC输出的分频脉冲触发拍照硬件级同步拍照瞬间PLC锁存当前编码器位置值Pos_Capture并通过TCP上报给上位机上位机收到图像后将推理结果与Pos_Capture绑定存入队列上位机根据剔除机构安装位置Pos_Reject计算剔除相位角Reject_Angle Pos_Reject - Pos_Capture Offset/// summary/// 产品追踪队列核心结构/// /summarypublicclassProductTrackItem{publiclongCapturePosition{get;set;}// 拍照时编码器位置publicDefectTypeDefect{get;set;}// AI推理结果publicfloatConfidence{get;set;}// 置信度publicintRejectAngle{get;set;}// 预计算剔除相位publicDateTimeCaptureTime{get;set;}// 用于超时清理publicboolIsProcessed{get;set;}// 是否已下发剔除指令}// 队列维护每收到PLC上报的新产品位置创建TrackItem// 每收到AI结果按CapturePosition匹配填充Defect字段// 定时扫描超过最大追踪距离仍未匹配的Item标记为丢失并告警⚠️ 避坑指南编码器位置会溢出回绕必须用有符号64位整数做差值运算或在PLC侧做位置展开。我们曾因32位计数器回绕导致剔除位置偏移整圈排查了两天才定位。三、 关键技术二AI推理与通讯的“流水线并行”200ms节拍下留给上位机的总窗口极其紧张。串行处理必死无疑。多线程流水线设计000 ms000 ms000 ms000 ms000 ms000 ms000 ms000 ms000 ms000 ms000 ms000 ms000 ms000 ms000 ms000 ms000 ms等待触发收图TCP下发剔除指令接收伺服定位TensorRT推理结果绑定相位计算采集线程推理线程调度线程PLC侧单产品处理时序目标lt;180msC#端关键优化点TensorRT引擎预热复用首次加载耗时数秒之后每次推理复用同一Engine实例。使用CUDA Stream实现异步推理CPU线程不被阻塞。零拷贝图像传输相机SDK直接输出GPU内存指针TensorRT直接读取避免CPU-GPU间Memcpy。实测节省15~20ms。TCP发送与推理并行上一产品的剔除指令下发与当前产品的AI推理在不同线程同时进行。结果缓存池预分配ProductTrackItem对象池避免GC抖动。高频场景下GC暂停可能导致单次超时。与汇川H5U的通讯协议精简剔除指令帧极致精简仅包含必要信息[帧头 2B][CMD 1B][产品序号 4B][剔除相位 4B][缺陷码 1B][CRC 2B][帧尾 2B]总长16字节单次TCP发送耗时1ms。PLC侧用中断优先级最高的通讯任务解析确保接收延迟可控。四、 关键技术三剔除执行的“容错与兜底”AI不可能100%准确通讯不可能永不丢包机械不可能永远精准。系统必须有兜底。三级防护机制层级机制触发条件动作L1置信度阈值过滤AI置信度0.7不剔除推入复检通道记录图像供人工复核L2通讯超时重传上位机下发后50ms未收到PLC ACK重传一次仍失败则标记该产品为疑似不良下游全检工位拦截L3剔除验证传感器剔除后良品通道传感器仍检测到产品立即停线报警提示剔除失效防止不良品流出PLC侧剔除FB设计要点使用凸轮表Cam Table而非简单延时。伺服根据上位机下发的相位角在精确位置执行剔除动作不受速度波动影响。剔除窗口可配置±5°容差适应机械磨损。每次剔除完成后主动上报“执行确认”给上位机形成闭环。// 汇川H5U ST语言凸轮剔除核心逻辑简化 IF bRejectCmd AND NOT bRejectDone THEN // 将上位机下发的相位角写入凸轮表主点 MC_CamTableSelect( CamTable : RejectCamTable, Periodic : FALSE, MasterAbsolute : TRUE, SlaveAbsolute : FALSE ); MC_CamIn( Master : EncoderAxis, Slave : RejectServoAxis, CamTable : RejectCamTable, MasterOffset : rRejectPhase, // 上位机计算的剔除相位 Execute : TRUE ); bRejectDone : TRUE; END_IF; // 剔除完成后复位标志等待下一次指令 IF bRejectDone AND MC_CamIn.Done THEN bRejectDone : FALSE; bRejectAck : TRUE; // 触发ACK上报 END_IF;五、 现场调试踩坑实录问题现象根因分析解决方案间歇性误剔良品相机触发信号受变频器干扰产生假触发触发线换屏蔽双绞线磁环PLC侧加数字滤波2ms高速时段剔除位置偏移上位机推理耗时突增相位计算基于过时位置引入“位置预测补偿”根据当前速度和历史延迟预估实际到达时间连续不良品漏剔AI推理队列积压旧结果覆盖新结果队列满时丢弃最旧未处理项告警而非覆盖同时动态降低相机帧率保护系统PLC偶发通讯断开工控机网卡节能模式导致休眠禁用网卡所有节能选项设置TCP KeepAlive5s应用层心跳200ms更换批次后剔除不准产品长度变化未更新剔除Offset配方中绑定产品尺寸参数切换配方时自动重算Offset并下发PLC校验 调试心得不要相信“理论上应该没问题”。在现场务必用示波器抓触发信号、用Wireshark抓TCP报文、用PLC Trace录编码器曲线。三重数据对齐才能定位那些“偶尔出现”的幽灵Bug。六、 性能指标与生产验证经过3个月连续生产验证系统达到以下指标检测节拍180ms/件含推理通讯剔除执行过杀率0.3%AI置信度阈值动态调整漏检率0.05%L3剔除验证兜底MTBF720小时无计划外停机AI推理平均耗时48msP9965ms最关键的是剔除准确率不再依赖AI模型的绝对精度而是靠“时空绑定闭环验证”的系统工程保证。即使模型偶尔犯错系统也能兜住底线。七、 写在最后AI落地的本质是系统工程这个项目让我最深的体会是工业AI的竞争力30%在模型70%在工程化能力。汇川H5U的凸轮功能和Socket通讯为精准执行提供了基础C#上位机的多线程流水线和时空对齐算法弥补了AI的不确定性而三级容错机制则守住了质量底线。三者缺一不可。如果你也在做类似的AIPLC联动项目建议先把“产品追踪队列”和“剔除验证闭环”做扎实再去追求模型精度的最后1%。稳比准更重要。