📚 课程目录第2章 ctrlX AUTOMATION平台与机器视觉协同基础

2. ctrlX AUTOMATION平台与机器视觉协同基础

在把工业相机、镜头、光源和视觉算法接入 ctrlX AUTOMATION 之前，必须先理解这个平台内部“谁负责什么、数据怎么走、时间怎么对齐”。否则很容易出现一种典型现象：相机能出图，PLC 也能跑逻辑，但触发时刻与结果判定总是差几毫秒，或者视觉结果在控制器里读到的永远是上一帧。本章围绕 ctrlX OS、ctrlX Data Layer、ctrlX PLC 与实时通信机制，说明视觉系统与控制器协同的基本原理。

一、ctrlX OS：协同运行的底座

ctrlX OS 是运行在 ctrlX CORE 硬件上的实时 Linux 操作系统，它同时承载实时控制任务、非实时应用（如视觉服务、Web 界面、数据库）以及容器化应用。它的关键价值在于：把“硬实时”与“软实时/非实时”负载放在同一台设备上，并通过资源隔离保证 PLC 的周期抖动可控。视觉处理通常属于非实时或软实时负载，例如图像采集、特征提取、深度学习推理；而触发输出、结果锁存、剔除动作属于硬实时负载。ctrlX OS 通过 CPU 核绑定、实时优先级和 cgroup 限制，让视觉进程不会抢占 PLC 的实时时间片。

实际部署时，一个常见做法是把 ctrlX CORE 的 CPU 核划分为实时核与非实时核：PLC 任务绑定到实时核，视觉容器绑定到其余核。这样即使视觉推理出现 20~50 ms 的抖动，PLC 的 1 ms 周期任务仍能稳定运行。需要强调的是，视觉算法本身不要求硬实时，但“触发—曝光—结果回传”这条链路的时间必须可测量、可补偿。

二、ctrlX Data Layer：视觉与控制的公共数据空间

ctrlX Data Layer（简称 Data Layer）是平台内统一的数据访问层，它把 PLC 变量、应用数据、设备状态、视觉结果都映射为带路径的节点，例如 plc/app/Application/vision/result/ok 或 vision/camera1/trigger。任何授权应用都可以通过路径读写这些节点，而不需要点对点私有协议。对机器视觉协同而言，Data Layer 解决了三个问题：第一，视觉结果以结构化节点形式暴露，PLC 无需解析自定义报文；第二，读写操作有明确的数据类型与时间戳，便于判断数据新鲜度；第三，跨应用通信不依赖额外网关。

但 Data Layer 不是实时通道。它的读写通常走进程间通信，延迟在亚毫秒到数毫秒量级，且受系统负载影响。因此它适合传递“结果”“参数”“状态”，不适合直接承载每毫秒一次的硬触发信号。硬触发应走实时通信机制，Data Layer 负责把结果和上下文交给 PLC 逻辑。

三、ctrlX PLC：协同逻辑的执行者

ctrlX PLC 遵循 IEC 61131-3，支持 LD、ST、FBD 等语言，运行在 ctrlX OS 的实时侧。在视觉协同中，PLC 通常承担四类职责：发出触发信号、管理相机状态机、接收并校验视觉结果、驱动执行机构（如气缸、伺服、剔除阀）。以 ST 语言为例，一个简化的结果校验逻辑如下：

// 示例：读取视觉结果并做超时与有效性判断
IF bTrigger THEN
    nTimeout := nTimeout + 1;
    IF nTimeout > 50 THEN          // 50 个 PLC 周期，约 50 ms
        bVisionFault := TRUE;      // 视觉未在窗口内返回
        bTrigger := FALSE;
    END_IF;
END_IF;

IF bResultValid THEN
    bPartOK := bVisionOK AND NOT bVisionFault;
    bTrigger := FALSE;
    nTimeout := 0;
END_IF;

这段逻辑的关键不是语法，而是“超时窗口”和“结果有效性”必须由 PLC 明确管理。视觉系统可能因为曝光不足、通信丢包或算法异常而不返回结果，PLC 不能无限等待。示例中的 50 ms 是假设值，实际应根据相机帧率、曝光时间和通信链路实测确定。

四、实时通信机制：触发与结果的时间对齐

视觉协同的精度瓶颈往往不在算法，而在时间对齐。常见链路是：PLC 在某个位置输出触发信号 → 相机接收触发并曝光 → 图像传输到视觉应用 → 算法处理 → 结果写回 Data Layer 或实时通道 → PLC 读取结果并执行动作。每一段都有延迟，且延迟可能波动。工程上需要区分三类时间：触发到曝光的固定延迟、曝光与传输的变动延迟、算法处理时间。固定延迟可以通过提前量补偿，变动延迟则要靠超时窗口和结果锁存来兜底。

如果使用实时以太网（如 EtherCAT）连接相机或远程 IO，触发信号可以做到微秒级同步；如果相机通过 GigE Vision 或 USB 连接，触发抖动通常在几十微秒到几毫秒。选择哪种方式，取决于节拍要求和允许的判定窗口。对于高速剔除场景，通常要求从触发到结果回传控制在 5~10 ms 内；对于一般装配检测，20~50 ms 往往可以接受。

五、协同的基本原理与工程判断

把上述四部分合起来看，视觉与控制器协同的本质是“用确定性的控制逻辑管理不确定性的视觉处理”。PLC 负责确定性的时序、触发和动作；视觉应用负责图像理解和结果生成；Data Layer 负责把结果变成可读写的结构化数据；实时通信负责把触发和关键信号的时间抖动压到可接受范围。四者各司其职，不能互相替代。

工程上判断协同是否健康，可以观察三个指标：第一，触发到结果回传的总时间是否稳定，波动是否小于判定窗口；第二，结果丢失或超时的比例是否在可接受范围内；第三，PLC 是否能在视觉异常时进入安全状态而不是死等。示例参数方面，若相机帧率为 60 fps、曝光 2 ms、图像传输 3 ms、算法处理 15 ms，则从触发到结果回传的理论下限约为 20 ms，实际应预留 30%~50% 余量，即判定窗口设为 30 ms 左右较为稳妥。这些数值属于教学示例，实际项目应以现场实测为准。

Data Layer 适合传结果和参数，不适合传每毫秒一次的硬触发；硬触发应走实时通信或 PLC 本地输出。两者分工明确，协同才稳定。

理解这一层基础后，后续配置相机、编写 PLC 逻辑、调试触发时序时，就能清楚每一步在整条链路中的位置，而不是把问题笼统地归为“视觉不准”或“PLC 太慢”。