1. 课程导入与协同架构总览

在一条典型的包装或装配产线上，ControlLogix PLC 负责运动、气缸、输送线与安全联锁，机器视觉系统负责定位、测量、字符识别与缺陷判定。两者若各自为政，就会出现“相机判了 NG，PLC 却已经把工件放行”这类事故。本课程要解决的核心问题，就是让视觉的判定结果以确定、可追溯、可诊断的方式进入 PLC 的控制逻辑，并让 PLC 的节拍与状态反过来约束视觉的触发与曝光时机。

先明确本节要建立的整体认知：ControlLogix 与机器视觉的协同，本质上是三条流在同一套硬件与网络上的并行运行——数据流（图像、结果、坐标、字符）、控制流（触发、使能、复位、联锁）和状态流（就绪、忙、完成、故障）。三者共用一条 EtherNet/IP 链路，但实时性要求完全不同：控制流要求毫秒级确定性，数据流允许几十毫秒的抖动，状态流则必须始终可读。理解这一点，后续所有配置与排障才有依据。

典型拓扑：谁连谁，走什么协议

最常见的架构是“PLC 为控制主站、视觉为智能从站”。ControlLogix 机架内放置 1756-L8x 系列控制器与 1756-EN2T/EN3TR 以太网模块，通过工业交换机连接视觉控制器（如康耐视 In-Sight、基恩士 CV-X 或 Keyence IV 系列，或基于 PC 的 VisionPro/Deep Learning 系统）。视觉控制器再通过 GigE Vision 或 USB3 Vision 连接相机，通过 I/O 或以太网连接光源控制器。

这里有一个关键分工：相机与视觉控制器之间的图像传输不经过 PLC。PLC 只接收视觉控制器处理后的“结论”，例如 Pass/Fail、X/Y/角度偏移、字符字符串、缺陷面积。把原始图像塞进 PLC 是典型的架构错误，会瞬间打满网络与控制器内存。PLC 与视觉之间交换的是结构化标签数据，而不是像素。

数据流：从像素到标签

视觉侧的处理链是“采集 → 定位 → 测量/识别 → 判定 → 输出”。以定位为例，相机拍到的图像先经过模板匹配或斑点分析，得到工件在图像坐标系中的像素位置，再通过标定矩阵换算为物理坐标（毫米、角度）。这个换算结果才是 PLC 真正需要的量。假设标定得到 1 像素 = 0.05 mm，模板匹配中心为 (642, 518) 像素，而示教基准为 (640, 520) 像素，则偏移量为 ΔX = (642−640)×0.05 = +0.10 mm，ΔY = (518−520)×0.05 = −0.10 mm。PLC 收到这两个浮点数后，可直接叠加到运动指令的目标位置上做补偿。

在 ControlLogix 侧，这些量通常映射为 REAL 或 DINT 类型的标签，例如 Vision1.Result.Pass（BOOL）、Vision1.Result.OffsetX（REAL）、Vision1.Result.Code（STRING）。数据通过 EtherNet/IP 的隐式 I/O 连接或显式 MSG 指令传输。隐式连接适合高频、固定长度的结果数据，周期可设为 2～10 ms；显式 MSG 适合低频、变长的字符串或配方数据。选择哪种，取决于该数据是否参与每个节拍的控制判断。

控制流：触发与握手的时序

控制流最容易出错的地方是“触发时机”与“结果读取时机”不匹配。正确做法是采用握手：PLC 置位 Trigger，视觉检测到上升沿后开始采集，采集与处理完成后置位 AcquisitionDone 与 ResultReady，PLC 在 ResultReady 为真时读取结果，读取完成后置位 Reset，视觉清除 ResultReady，一个周期结束。若 PLC 在 ResultReady 之前就读结果，会读到上一件的旧数据——这是现场最常见的“偶发误判”根因。

项目目标与验收标准

一个可交付的协同项目，至少应满足以下可验证目标：单件视觉处理时间稳定在节拍预算内（例如 80 ms 以内）；从触发到 PLC 可读结果的端到端延迟可测量且波动小于 10 ms；通信中断时 PLC 能在 100 ms 内进入安全状态并报警；所有判定结果可追溯到工件序号与时间戳。这些指标不是装饰，而是后续章节中配置 RPI、优化曝光、设计故障处理逻辑的直接依据。

下表给出一个教学示例的标签映射与验收参考，实际项目应按现场节拍与视觉工具耗时调整。

把这三条流和上述目标记牢，后面每一章都会回到同一个判断标准：这条数据是否在正确的时刻、以正确的类型、被正确的逻辑使用。架构清晰了，配置和排障才不会变成碰运气。