双目相机在实验台上跑通算法只是一半，真正上线时工程师面对的是另一组问题：产线 PLC 怎么知道该拍照了、相机算完的结果怎么回传、时序对不上时是等还是跳、断线了会不会堵死整条产线。这些问题的优先级高于算法调优——链路不通，算得再准也白搭。
朗锐创新在工业级双目相机的项目交付里，产控接入是与算法并列的交付项。经验是：把"谁触发、怎么等、结果回给谁、时序怎么对"这四个问题在方案阶段想清，再选协议与部署形态，上线后的联调周期通常能压缩一半以上。本文按触发、协议、数据、时序四层把这条链路一次讲清。
关键要点 - 接入产控分四层：触发层（谁让相机拍照）、通信层（用什么协议）、数据层（回传什么内容）、时序层（各环节怎么对齐），出问题大多在这四层的边界上。 - 硬件 IO 触发抖动通常在微秒到毫秒级，软触发经网络下发常见 1–10ms，运动或高节拍场景优先硬触发。 - 协议选型的实用结论：多数检测场景用 Modbus TCP 加硬 IO 即可，实时性要求高再上 PROFINET/EtherCAT，数据结构复杂考虑 OPC UA。 - MES/SCADA 要的是结构化结果与可追溯数据，不是原始点云；边缘侧先算好合格判定与测量值再上报。 - 朗锐创新的工业级双目相机按项目定制交付，触发方式、协议栈与寄存器映射会随场景写进验收清单。
一、先分清四层：问题都出在边界上
把链路拆成四层，出问题时才能快速定位是哪一层的事。
触发层：产线给相机一个"现在拍"的信号。可以是硬件电平（IO 触发），也可以是网络指令（软触发）。
通信层：相机、边缘算力与 PLC/MES 之间用什么协议说话。常见有 Modbus TCP、PROFINET、EtherCAT、OPC UA 与 MQTT。
数据层：回传的内容是什么。是原始点云、测量值，还是合格判定与缺陷坐标。
时序层：触发、曝光、传输、计算、回传各环节的时间对齐。这一层最容易出"偶发性"问题。
四层之间的边界是排查重点。例如"偶发漏检"可能是时序层的问题（触发没对齐），也可能是数据层的问题（结果没写进去 PLC 就读了）。分层定位比笼统说"通信不稳"有效得多。
二、部署形态：相机直连还是工控机中转
双目与单目在部署上有个显著差别：双目的视差计算通常需要一定的算力，多数方案是"相机 + 工控机/边缘盒"两段式。
相机直连 PLC：仅适用于相机内置算法、直接输出结果的高端型号。优点是链路短、时延低；缺点是算法固定、难以按场景调优。
工控机中转：相机经 GigE Vision 或 USB3 Vision 接入工控机，视差计算与测量在工控机完成，结果再经工业以太网与 PLC 交互。这是最常见也最灵活的形态。
边缘盒形态：算法跑在 Jetson、昇腾或 RK 等嵌入式平台上，适合空间受限或需要分布部署的产线。
对 PLC 的呈现：无论哪种形态，PLC 侧看到的都应该是"一组寄存器或一条消息"，内部是几段式对 PLC 是透明的。这一点要在方案阶段约定清楚，避免 PLC 工程师和视觉工程师各写一半。
接口与扩展能力的选型，可参考双目相机选型参数。
三、触发：硬件 IO 与软触发怎么选
触发方式直接决定时序稳定性，是四层里最该早定的。
硬件 IO 触发：PLC 输出一个电平脉冲给相机的触发线。抖动通常在微秒到毫秒级，运动场景优先选择。注意光电隔离与线缆长度，长距离建议用差分信号。
软触发：PLC 或上位机通过网络下发指令。好处是灵活、可携带参数（如 ROI 配置）；代价是抖动常见 1–10ms，且依赖网络负载。
混合模式：产线节拍触发用硬 IO，配置类指令（改参数、切配方）走网络。这是多数产线的实际形态。
握手信号设计：完整的握手至少包含三个信号——触发（Trigger）、忙（Busy，相机正在处理）、完成（Done，结果已就绪）。缺了 Busy/Done，PLC 就只能盲等，要么浪费节拍要么读到旧数据。
触发丢失的处理：要约定"触发到来时上一帧还没算完"的策略——是丢弃新触发（推荐，不堵产线）还是排队。这个策略不写进设计，联调时一定会扯皮。
视觉与 PLC 的握手约定，建议在需求确认单里用一张时序图写清。集成的整体方法可参考双目相机集成指南。
四、协议选型：从 Modbus TCP 到 OPC UA
协议没有绝对好坏，按实时性、数据复杂度与现场生态来选。
Modbus TCP：部署最快、PLC 支持面最广，寄存器读写简单。周期性轮询的响应在 10–100ms 量级，对多数检测场景（节拍 100–500ms）足够。缺点是数据结构表达能力弱，浮点与字符串要自己做映射，还要注意字节序。
PROFINET：西门子生态的主流，实时版（RT/IRT）周期可到 1–10ms 级，适合与 PLC 紧耦合的同步场景。需要网络设备支持与组态配置。
EtherCAT：实时性最高，周期可达 100μs 级，多轴运动控制场景常用。作为从站的视觉设备相对少，通常是工控机作为 EtherCAT 主站的一部分再与视觉交互。
OPC UA：数据模型能力强，适合结构化数据与跨品牌互通，常用于 MES/SCADA 层而非底层实时控制。信息模型按 Companion Specification 对齐可显著减少对接工作量。
MQTT：轻量发布订阅，适合云端与数据采集层，不适合实时控制。常与篇二的云链路配合使用。
一个实用的组合是：底层触发用硬 IO，实时交互用 Modbus TCP 或 PROFINET，MES 层用 OPC UA 或 REST。多数产线用"硬 IO 加 Modbus TCP"就能跑稳，不必为了协议先进性增加复杂度。
五、结果回传与 MES/SCADA 上报
PLC 关心的是控制与判定，MES 关心的是追溯与统计，两者要的数据不一样。
给 PLC 的内容：合格/不合格判定、测量值、工位状态。通常映射成寄存器或报文，长度固定、语义明确，附上帧号或时间戳便于对账。
给 MES 的内容：每个工件的检测记录，包括时间戳、工件 ID、测量结果、判定、缺陷类型与位置、设备状态。结构化、可查询、可追溯。
数据格式的坑：浮点字节序（大端/小端）、字符串编码、寄存器位宽，这三处是对接中返工最多的地方。建议在联调前用一段双方确认的样例数据对齐格式。
原始数据不上 MES：原始图像与点云体量大，MES 只存结果与必要的缩略图或异常片段。完整数据放边缘或对象存储，按需调取。
数据保留策略：合格数据保留多久、异常数据保留多久，要按质量追溯要求提前定，避免磁盘写满导致停机。
六、时序验证与常见异常
联调阶段把时序验证做扎实，比上线后救火省得多。
时序验证方法：用示波器或逻辑分析仪抓触发线与 Done 信号，测量触发到结果就绪的实际耗时，与设计值比对。也可以在数据里打时间戳做离线核对。
端到端时延构成：触发响应、曝光、传输、算法、结果写入，各段分别测量。常见误区是只看相机帧率，忽略了算法耗时与网络传输。
典型异常一：偶发漏检。多数是触发与同步没对齐：工件到了但触发晚了，或者上一帧没处理完触发被丢。查时序图，不是查算法。
典型异常二：数据错位。PLC 读到的是上一个工件的结果。通常是 Done 握手不完整或寄存器映射有偏移。
典型异常三：断线堵产。网络闪断后相机或工控机没恢复，产线一直等。要有心跳超时、自动重连与超时放行（或超时报废）的明确策略。
看门狗：边缘侧算力挂掉时，PLC 侧应能通过心跳超时感知并进入安全状态，而不是永远等待。
联调前把这几种异常的应对策略写进设计，能显著减少上线后的反复。
七、验收清单
产控接入的验收建议覆盖以下几项。
握手时序：触发到结果就绪的实测耗时、抖动范围，与设计值比对。
连续运行：满节拍连续运行（如 8 小时）无漏触发、无数据错位、无断线停机。
异常恢复：断网重连、边缘侧重启、PLC 重启后链路能自动恢复，恢复时间明确。
数据正确性：抽样核对 PLC 侧显示结果与边缘侧原始结果一致，浮点与字节序无偏差。
寄存器/报文映射：双方确认的映射表版本化管理，变更留痕。
日志与追溯：每次触发的完整记录可查询，含触发时间、结果、耗时。
文档交付：时序图、映射表、异常处理策略、重连参数一并交付。
若联调中出现点云质量类问题（与链路无关），可参考双目相机故障排查区分是成像问题还是通信问题。
结论
双目相机接入产线的完整链路是四层：触发层定握手（Trigger/Busy/Done 三信号加丢帧策略），通信层按需选协议（多数场景硬 IO 加 Modbus TCP 足够，实时性要求高再上 PROFINET/EtherCAT），数据层把 PLC 要的判定与 MES 要的追溯分开（原始数据不上 MES），时序层用实测而不是估算验证（触发到结果就绪的耗时与抖动要测出来）。
出问题的位置大多在层与层的边界上，分层定位是排查的第一原则。朗锐创新的工业级双目相机按项目定制交付，触发方式、协议栈、寄存器映射与时序验证方法会作为交付物写进验收清单，联调前把异常应对策略约定清楚。把你的产线节拍、PLC 品牌与 MES 对接方式告诉我们，朗锐创新可以先出一版接入方案与时序设计。
常见问题（FAQ）
Q1：双目相机能直接连 PLC 吗，还是要经工控机？ 分两种情况。内置算法、直接输出结果的高端相机可以直连，但算法固定、难以按场景调优；更常见的形态是相机经 GigE Vision 或 USB3 Vision 接入工控机或边缘盒，视差计算与测量在边缘完成，结果再经工业以太网与 PLC 交互。无论哪种形态，PLC 侧看到的都应是一组寄存器或一条消息，内部结构对 PLC 透明。朗锐创新在定制项目里会按节拍与算力需求推荐部署形态，并把寄存器映射表作为交付物。
Q2：Modbus TCP、PROFINET、EtherCAT 怎么选？ 看三个变量：实时性要求、PLC 品牌、数据复杂度。多数检测场景（节拍 100–500ms）用 Modbus TCP 加硬 IO 触发就够，部署最快、支持面最广；与 PLC 紧耦合的同步场景选 PROFINET（实时周期 1–10ms 级）；多轴运动控制场景才需要 EtherCAT（周期可达 100μs 级）。数据结构复杂、跨品牌互通多的 MES/SCADA 层用 OPC UA。朗锐创新会按你的现场协议生态推荐组合，不为协议先进性增加复杂度。
Q3：触发信号怎么设计才不会出偶发问题？ 完整的握手至少三个信号：触发（Trigger）、忙（Busy）、完成（Done）。缺了 Busy/Done，PLC 只能盲等，要么浪费节拍要么读到旧数据。运动场景用硬件 IO 触发，抖动在微秒到毫秒级；软触发经网络下发常见 1–10ms 抖动，只适合静态或低节拍场景。还要约定触发到来时上一帧没算完怎么办？推荐丢弃新触发而不是排队。朗锐创新在需求阶段会用时序图把握手约定写清，联调按图验证。
Q4：结果回传 MES，原始点云也一起传吗？ 不建议。MES 关心的是结构化结果与追溯：时间戳、工件 ID、测量值、判定、缺陷位置。原始点云单帧可达十几 MB，全量上传既占带宽也拖慢 MES。常见做法是边缘侧只上报结果与必要的异常片段，完整图像与点云放边缘存储或对象存储，按需调取。数据保留策略要按质量追溯要求提前定，避免磁盘写满。朗锐创新在方案里会把"给 PLC 的"与"给 MES 的"数据分开定义，各自走各自的最短路径。
Q5：联调时数据总错位，PLC 读到的是上一个工件的结果，怎么查？ 优先查握手与映射，而不是查算法。三种常见原因：Done 信号不完整导致 PLC 提前读取；寄存器映射有偏移，浮点或字节序没对齐；工件 ID 与帧号的对应关系断了。排查方法是抓触发线与 Done 的时序，核对一次触发的完整生命周期里每个环节的时间点，再抽样比对 PLC 侧与边缘侧的原始结果。朗锐创新在联调阶段会提供时序实测数据与样例报文，把格式类问题在联调前对齐掉。
Q6：网络断线后相机这边会堵死产线吗？ 不会，前提是设计了恢复策略。三件事要做：心跳超时（PLC 侧定期检测视觉侧是否在线）、自动重连（断线后边缘侧按固定间隔重试）、超时放行或报废（等待超过阈值时按预设策略处理而不是永远等待）。这三项没有约定，网络闪断一次就可能堵产线。建议在验收时做异常演练：主动断网、重启边缘侧、重启 PLC，确认链路能自动恢复且恢复时间明确。朗锐创新在交付时会附上异常处理策略文档与重连参数。
