1. 产线节拍瓶颈诊断
在高速产线上，视觉系统“跟不上”往往不是单一原因造成的。相机可能拍得够快，但图像传输慢；算法可能算得够快，但通信握手拖了后腿；或者触发信号本身就不稳定。如果只盯着“总耗时”这一个数字，就像医生只看体温不看血常规——知道发烧，却不知道是感染还是炎症。In-Sight 提供的采集时间戳、处理耗时和通信延迟数据，正是把“总节拍”拆成可归因分量的三把手术刀。
一、节拍分解：把一次检测拆成四段
在 In-Sight 的作业流程中，一次完整的检测周期可以分解为四个时间分量。理解这个分解，是瓶颈诊断的起点。
- 触发到采集（Trigger→Acquire）：从外部触发信号到达相机，到图像传感器完成曝光并锁定一帧图像的时间。它包含触发延迟、曝光时间和读出时间。高速产线上，曝光时间通常被压得很短（例如 50～200 μs），但触发信号的抖动和相机内部排队可能让这一段悄悄变长。
- 采集到处理开始（Acquire→Process）：图像从传感器搬运到处理引擎、完成预处理（如灰度转换、ROI 裁剪）的时间。这一段常被忽略，但在高分辨率或高帧率下，数据搬运可能成为隐形瓶颈。
- 处理耗时（Process Time）：In-Sight 执行视觉工具链（定位、测量、读码、判断）的实际计算时间。这是最容易被关注的一段，但未必是瓶颈所在。
- 处理完成到输出（Process→Output）：结果通过以太网/IP、PROFINET、数字 I/O 或串口发送给 PLC 或执行机构的时间，包含通信协议封装、网络传输和接收方确认。
总节拍 = 四段之和 + 系统调度开销。瓶颈诊断的核心，就是找出哪一段在总时间中占比异常，并且随产线速度变化而恶化。
二、In-Sight 中可获取的时间数据
In-Sight 的电子表格和事件日志中，可以提取到以下关键时间信息（具体字段名因固件版本略有差异，但语义一致）：
- Acquisition Timestamp：图像采集完成的绝对时间戳，精度通常为毫秒级或更高。
- Trigger Timestamp：触发信号被相机确认的时间戳。
- Process Start / Process End：处理引擎开始和结束执行作业的时间戳。
- Output Timestamp：结果被写入通信缓冲区或 I/O 端口的时间戳。
通过这些时间戳，可以计算出每一段的耗时。例如：
采集耗时 = Acquisition Timestamp - Trigger Timestamp
处理耗时 = Process End - Process Start
通信延迟 = Output Timestamp - Process End
总周期 = Output Timestamp - Trigger Timestamp在 In-Sight 的电子表格中，可以使用 GetSystemTime 或事件日志导出功能获取这些时间戳。更实用的做法是：在作业中插入时间戳记录函数，将每次检测的四个时间点写入一个数据缓冲区，再通过 FTP 或 TCP 导出为 CSV，供离线分析。
三、瓶颈识别的判断逻辑
拿到四段数据后，不要只看平均值。高速产线的瓶颈往往藏在“尾部”——即最慢的那 5% 或 1% 的周期。判断逻辑如下：
- 计算每段的 P50、P95 和 P99 分位数。如果某一段的 P99 远大于 P50，说明该段存在偶发性阻塞或排队。
- 观察各段与产线速度的相关性。逐步提高产线速度（或缩短触发间隔），看哪一段的耗时随之上升。上升最快的那一段，就是速度瓶颈。
- 检查段间重叠。理想情况下，采集和处理可以流水线重叠。如果 Process Start 总是等于 Acquisition Timestamp，说明没有重叠，处理引擎在等待图像搬运完成。
- 对比触发间隔与总周期。如果总周期接近或超过触发间隔，说明系统已经在满负荷边缘，任何抖动都会导致丢帧。
四、典型瓶颈模式与对应数据特征
不同瓶颈在时间数据上会呈现不同的“指纹”。以下是一个示例性的对照表，参数为合理假设，用于说明判断方法：
| 瓶颈类型 | 数据特征 | 可能原因 |
|---|---|---|
| 触发抖动 | Trigger→Acquire 的 P99 显著大于 P50，且与产线机械振动相关 | 触发传感器安装松动、信号线屏蔽不良、PLC 扫描周期抖动 |
| 曝光/光照不足 | Acquire 段耗时稳定但偏长，图像偏暗 | 曝光时间设置过长，或光源亮度不足导致相机自动延长曝光 |
| 处理算法过重 | Process Time 的 P50 就很高，且随 ROI 增大而线性上升 | 工具链中包含了高复杂度工具（如 PatMax 多模板匹配、OCR 全图搜索） |
| 通信阻塞 | Process→Output 的 P99 突增，且与 PLC 扫描周期或网络负载相关 | 以太网/IP 连接数过多、交换机拥塞、PLC 未及时读取结果 |
| 流水线未重叠 | Process Start 紧贴 Acquisition Timestamp，总周期 ≈ 四段之和 | 相机设置为“采集完成后才允许下一次触发”，未启用流水线模式 |
五、从数据到行动：一个诊断示例
假设某产线节拍要求为 120 ms/件，即每分钟 500 件。现场反馈“偶尔丢帧”。导出 1000 次检测的时间戳后，得到以下示例数据（合理假设）：
- Trigger→Acquire：P50 = 8 ms，P99 = 35 ms
- Acquire→Process：P50 = 5 ms，P99 = 6 ms
- Process Time：P50 = 42 ms，P99 = 45 ms
- Process→Output：P50 = 12 ms，P99 = 48 ms
- 总周期：P50 = 67 ms，P99 = 134 ms
分析：P50 总周期 67 ms 远低于 120 ms，说明系统平均能力充足。但 P99 达到 134 ms，超过了节拍要求，这解释了“偶尔丢帧”。进一步看，Trigger→Acquire 的 P99 为 35 ms（是 P50 的 4 倍多），Process→Output 的 P99 为 48 ms（是 P50 的 4 倍），这两段是尾部延迟的主要来源。处理耗时本身很稳定，不是瓶颈。
行动方向：优先检查触发传感器的信号质量和屏蔽，同时检查通信链路的负载和 PLC 读取时序。而不是去优化视觉算法——因为算法不是问题所在。
六、建立可复用的诊断流程
把上述方法固化为一个可重复执行的流程，可以显著缩短排障时间：
- 数据采集：在 In-Sight 作业中启用时间戳记录，连续采集至少 1000 个周期，覆盖产线从低速到高速的完整范围。
- 分段统计：对四段耗时分别计算 P50、P95、P99，并计算各段占总周期的比例。
- 尾部定位：找出 P99/P50 比值最大的段，以及 P99 绝对值最大的段。两者可能不同，前者指示抖动源，后者指示容量瓶颈。
- 相关性验证：改变产线速度或触发间隔，观察各段耗时的变化趋势，确认瓶颈段。
- 针对性整改：根据瓶颈类型采取对应措施，整改后重新采集数据，对比 P99 是否降至节拍以内。
节拍瓶颈诊断的本质，是把“慢”这个模糊感受，转化为可测量、可归因、可验证的时间分量。In-Sight 的时间戳数据提供了这种转化的基础，而分位数分析和相关性验证则提供了判断依据。掌握这套方法后，面对高速产线的节拍问题，就不再需要凭经验猜测，而是可以沿着数据链条一步步定位到真正的瓶颈。