电话/手机：联系客服
优质评论内容
这种情况 大概率不是“拍不到”，而是“来不及算完”。
你已经观察到一个很关键的信息：
抓拍图像正常
提速后频繁漏检
处理速度跟不上
这说明问题重点已经从 成像链路，转到 节拍链路和算法耗时 了。
也就是说，现在更像是：
相机能看到，但在下一个产品到来前，上一张还没处理完。
所以先给结论：
一、先说判断结论
你这个问题通常就落在这 4 类里：
OCR 工具耗时太长
ROI 太大，搜索范围太宽
触发时序不稳，图像虽然有，但识别位置漂
相机内部任务流程串行，120/min 时节拍被打满
你现在的产能是：
原来：60 个/分钟 = 1 秒 1 个
现在：120 个/分钟 = 0.5 秒 1 个
也就是说，你整套视觉流程从“拍照+预处理+定位+OCR+输出结果”，
必须稳定压到 500ms以内，而且最好留足余量，实际最好做到：
单次总耗时 ≤ 200~300ms
否则就会开始随机漏检。
二、先别急着怀疑触发，先分清“漏检”到底是哪一种
现场很多人说“漏检”，其实有 3 种完全不同的故障：
1. 根本没拍到
表现：
没有对应图片
或图片错位严重
这是 触发/时序/延迟问题
2. 拍到了，但没来得及处理
表现：
图片有
结果输出超时
或下一件已经来了，上一件还没算完
这是 处理节拍问题
3. 拍到了，也处理了，但识别失败
表现：
OCR NG 增多
字符定位不稳
部分图片正常、部分失败
这是 算法鲁棒性问题
你现在说“图像抓拍正常，但处理速度跟不上”，那优先级就是：
先查处理耗时
再查触发时序
最后再查算法细节
三、120 个/分钟时，最常见的瓶颈不是曝光，而是 OCR 前面的“定位流程”
很多字符识别项目，不是 OCR 本身最慢，而是前面的这些步骤拖慢了：
全图查找产品
全图找边缘
全图模板匹配
多次坐标变换
多区域重复增强
多工具串行判定
最后 OCR 只是最后一步。
所以你要先看一件事：
单次视觉流程里，最耗时的是哪一步？
如果康耐视软件里能看到各工具执行时间，重点看：
定位工具耗时
图像预处理耗时
OCR 工具耗时
通讯/结果输出耗时
很多时候不是 OCR 慢，而是你为了让 OCR 更稳，前面加了太多步骤。
四、不换相机，最有效的优化方向：先砍 ROI
这个是现场提速最有效的办法之一。
如果你现在 OCR 是在：
整张图大范围搜索字符
那一定慢。
应该改成：
先粗定位产品
再把字符区域裁成很小的 ROI
最后只在小区域做 OCR
比如原图是：
1600 × 1200
字符区其实只占：
300 × 80
那你还在全图做 OCR，纯属浪费算力。
经验上：ROI 缩小以后，速度提升往往最明显。
五、字符识别不要“全能识别”，要“限定识别”
如果你的字符规则是已知的，比如：
只会出现数字
或固定格式：2 个字母 + 4 个数字
或固定长度 8 位
那一定要在 OCR 里做约束。
比如限制：
字符集只允许 0-9
禁止小写字母
固定长度
固定字符间距范围
固定读向
这样做的意义很大：
速度更快
误识别更少
很多项目慢，就是因为 OCR 工具还在猜：
A/B/C/D...
0/O
1/I
8/B
如果业务上根本不可能出现字母，那就别让它猜。
六、能不用“全图定位 + 全图OCR”，就不要这么干
更好的逻辑一般是：
触发拍照
→ 找基准点/特征
→ 建立局部坐标
→ 抠出字符区
→ OCR
→ 输出
而不是：
触发拍照
→ 整图增强
→ 整图搜索
→ 整图 OCR
→ 再判断是不是目标字符
后者在 60 个/分钟可能还能扛，
到 120 个/分钟就容易崩。
七、图像预处理别做太重
很多项目为了提高识别率，会堆很多预处理：
平滑
锐化
对比度增强
二值化
开闭运算
去噪
连通域筛选
这些每一步都在吃时间。
要注意一件事：
120 个/分钟时，最好的算法不是“最复杂最稳”的，而是“刚好够用且最快”的。
你可以这样优化：
保留真正有效的步骤
比如：
只保留一个简单对比增强
或只做一次阈值分割
删除重复处理
很多工程里有两三次类似增强，其实收益很小。
减少多分支判断
别一张图失败后又走第二套、第三套备用逻辑。
这种“保险逻辑”一提速就最容易拖死节拍。
八、触发信号当然也可能有延迟，但你的描述更像“系统排队”
触发问题要分两种。
第一种：触发晚了
产品已经走过最佳位置才拍，
图像可能仍然“正常”，但字符位置发生偏移，识别窗口不准。
这时表现通常是：
图像不是没有，而是字符在画面里的位置漂
有时识别到，有时识别不到
提速后更明显
第二种：触发本身没问题，但相机忙不过来
比如上一张还在处理，下一张触发已经来了。
这时会出现：
触发脉冲来了
但相机或任务队列拥塞
有些帧被丢掉或超时
表面看成“漏检”
这个在节拍翻倍后特别常见。
所以你要查：
相机是否有 busy/ready 状态信号
PLC 是否在相机忙时仍继续发触发
有没有触发最小间隔限制
有没有结果返回超时
九、一个很关键的现场问题：PLC 触发和编码器补偿有没有重新算
线速从 60 提到 120，意味着：
产品移动速度变快
从光电到拍照点的位移时间缩短
字符在画面里的位置变化更敏感
如果你原来是：
光电触发 → 延时 X ms → 相机采图
那提速后原来的延时值可能已经不对了。
这时虽然你看到“图像也有”，但可能：
字符没到最佳中心位置
或产品轻微抖动时被拍下
或 ROI 边界卡得太紧
所以要重新核查：
触发传感器到拍照点的机械距离
当前线速度
延时触发时间
字符进入 ROI 的位置余量
尤其是 固定延时触发 的系统，提速后很容易出问题。
十、最容易见效的优化顺序
按现场收益排序，我建议你这样改。
1）先看单次任务总耗时
目标不是“能跑”，而是要看：
一次完整检测到底用了多少 ms
如果已经接近或超过 500ms，肯定会漏。
2）缩小 ROI
这是第一优先级。
能从全图缩到局部，就先做这个。
3）限定 OCR 字符集和长度
把识别范围尽量收紧。
4）减少预处理步骤
删掉那些“锦上添花但耗时”的操作。
5）先定位，再 OCR
不要直接大范围 OCR。
6）检查触发延时是否随线速重算
尤其是光电+定时延时的方案。
7）检查相机 busy/ready 握手
避免 PLC 在相机没处理完时继续触发。
十一、如果是 Cognex 项目，常见的提速思路其实很固定
虽然不同型号软件界面不一样，但提速思路基本一致：
思路1：减少工具数量
一个任务里如果堆了很多工具，速度一定掉。
思路2：前级粗定位，后级小窗口识别
不要让 OCR 自己去全图找。
思路3：降低不必要的图像分辨率
如果字符本身不小，不一定非要最高分辨率。
适当降低后，速度会明显提升。
思路4：结果逻辑简化
不要做太多字符串比对、分支补判、二次重试。
思路5：异步输出或缩短通讯阻塞
有时不是识别慢，而是等 PLC / 上位机通讯确认慢。
十二、你可以用一个最笨但很有效的实验来定位
做 3 组测试：
A组：只拍照，不识别
看 120 个/分钟能不能稳定不漏触发。
如果都稳，说明相机采图链路大概率没问题。
B组：拍照 + 最简 OCR
把定位、预处理全部简化，只保留最核心识别。
如果这时稳定，说明是算法太重。
C组：完整流程 + 降速回测
如果降回 60 就完全正常，升到 120 才不行，
基本就是节拍裕量不够，而不是随机硬件坏。
这个方法非常快，能把问题直接切成：
触发问题
算法耗时问题
稳定性问题
十三、我个人根据你的描述，最怀疑的不是“快门”，而是这三个点
按概率排序：
第一：OCR/定位逻辑太重
因为你已经明确说了“图像抓拍正常，但处理速度跟不上”。
第二：触发延时没有随着线速重算
导致图像虽然有，但字符进入 ROI 的时机不稳定。
第三：PLC 没有和相机做 busy/ready 握手
节拍上来后，相机来不及，触发排队或丢帧。
十四、一个很实用的改法
如果现场字符位置相对固定，我会优先改成这种逻辑：
光电触发
→ 固定延时拍照（重新按120件/min计算）
→ 小区域 ROI
→ 只识别数字/固定字符集
→ 直接输出
如果字符位置有漂移，再加一个很轻量的定位工具：
先找一个边缘/基准角
→ 生成偏移坐标
→ OCR
不要一上来就模板匹配 + 多重滤波 + 大范围 OCR。
十五、给你一个节拍判断标准
120 个/分钟 = 500ms 一个产品。
现场为了稳，视觉任务最好满足：
拍照+识别总耗时 ≤ 250ms
最多别超过 300ms
留出通讯和波动余量
如果现在完整流程在 350~450ms，
现场就会表现成：
平时勉强能跑
一提速就漏检
十六、最后给你一个直接可执行的排查清单
你明天到现场可以按这个顺序试：
看单次任务总耗时，找到最慢工具
把 OCR ROI 缩到最小
限定字符集、长度、方向
删除不必要的预处理和备用分支
检查触发延时是否按新线速重算
看相机是否有 busy/ready，PLC 是否做了握手
做“只拍照不识别”和“最简识别”对比测试
必要时适当降图像分辨率