3. 机器人设备协同的通信基础

在 ctrlX AUTOMATION 平台上做机器人协同，最容易踩的坑不是“协议不会配”，而是把不同时间尺度的通信混在一条链路上：用 OPC UA 去发运动指令，或者用 MQTT 去等一个 1 ms 的同步信号。要避免这类问题，先要建立一张清晰的“通信地图”——哪些协议负责实时控制，哪些协议负责数据协同，它们在 ctrlX 里各自站在什么位置。

一、两类通信：实时控制面与数据协同面

机器人系统的通信需求可以粗分为两类。第一类是实时控制面：周期固定、抖动极小、要求确定性送达，典型周期在 250 µs～4 ms 之间，用于伺服使能、位置/速度设定值、状态字、同步信号。第二类是数据协同面：周期不敏感、允许百毫秒级延迟，用于机器人状态上报、程序下发、订单/工单交互、与 MES/SCADA/云端的对接。

ctrlX CORE 的价值在于它同时具备这两种能力：一侧是以 ctrlX OS 实时内核 + EtherCAT 主站为核心的确定性控制通道，另一侧是基于 Linux 侧应用（如 ctrlX Data Layer、OPC UA Server、MQTT Client）的数据通道。二者通过 ctrlX Data Layer 这一统一数据层解耦，而不是让实时任务直接去处理网络报文。

二、EtherCAT：机器人实时控制的主干

在 ctrlX CORE 上，EtherCAT 通常承担机器人本体与伺服驱动之间的实时链路。它采用“飞读飞写”的处理方式：主站发出一个以太网帧，从站在帧经过时直接读写自己的数据区，整帧绕一圈返回，因此周期时间与从站数量关系较弱，主要取决于拓扑长度和从站处理延迟。

关键配置参数包括：周期时间（如 1 ms）、分布式时钟 DC（使各从站时钟对齐到主站）、同步模式（SM-Synchronous 或 DC-Synchronous）、PDO 映射（把控制字、状态字、目标位置、实际位置映射到过程数据）。以一台六轴机器人为例，若每轴映射 4 字节控制字 + 4 字节状态字 + 4 字节目标位置 + 4 字节实际位置，则单轴 16 字节，六轴约 96 字节，加上 IO 与安全数据，整帧通常仍在 200 字节以内，1 ms 周期下总线负载很低。

判断 EtherCAT 是否健康，主要看三个量：Working Counter 是否稳定、DC 偏差是否在允许范围内（一般要求小于周期时间的 1/4）、丢帧/CRC 错误计数是否持续为 0。若 Working Counter 偶尔跳变，优先检查线缆屏蔽、终端电阻和从站供电，而不是先去改 PLC 程序。

三、PROFINET：与西门子生态协同的实时通道

当机器人工作站需要与西门子 PLC、分布式 IO 或第三方 PROFINET 设备协同时，ctrlX CORE 可作为 PROFINET 控制器或设备接入。PROFINET 分 RT（实时，周期约 1～10 ms）与 IRT（等时实时，周期可到 250 µs～1 ms，需专用硬件支持）。在机器人协同场景中，常见做法是：机器人本体走 EtherCAT 保证关节级实时性，工作站级的互锁、夹具、安全门信号走 PROFINET RT，两者在 ctrlX CORE 的 PLC 任务中做逻辑汇合。

需要特别注意的是时钟同步：PROFINET IRT 依赖 PTCP 同步，若与 EtherCAT DC 混用，必须在 ctrlX 侧明确哪个是主时钟源，避免两个同步域互相拉扯导致抖动放大。

四、OPC UA：语义化的数据协同与信息建模

OPC UA 在 ctrlX 中的角色不是“快”，而是“清楚”。它提供带类型、带语义的信息模型：机器人可以被建模为一个对象，下面挂载 Axis[1..6]、Status、Program、Tool 等节点，每个节点有明确的数据类型和访问权限。ctrlX Data Layer 的节点可以通过 OPC UA Server 暴露给上位系统，也可以由 OPC UA Client 主动去读外部设备。

典型用法是：MES 通过 OPC UA 读取机器人当前作业号、循环时间、报警代码；同时通过方法调用（Method Call）下发“切换程序”“复位报警”等命令。这些操作的时间尺度在几十到几百毫秒，完全落在 OPC UA 的舒适区。若把 OPC UA 订阅周期设到 10 ms 以下去追实时位置，会同时压垮服务器和网络，且仍无法保证确定性。

五、MQTT：轻量上报与跨系统事件分发

MQTT 采用发布/订阅模型，通过 Broker 解耦生产者和消费者，主题（Topic）分层，如 ctrlx/robot01/status、ctrlx/robot01/alarm。它适合把机器人状态、产量计数、报警事件推送到边缘网关或云平台。QoS 0 最快但可能丢，QoS 1 至少一次但可能重复，QoS 2 恰好一次但开销最大。对于状态上报，QoS 1 通常足够；对于计件数据，建议在 payload 中带唯一序号做去重。

MQTT 的边界同样明确：不要用它传控制指令。Broker 的转发延迟、网络抖动、QoS 重传都会让指令到达时间不可预测。它适合“告知发生了什么”，不适合“要求什么时候必须发生”。

六、边界判断：一张可执行的选型对照

实际工程中，可以用下面这张对照表快速判断某个信号该走哪条通道。判断依据是三个问题：这个信号是否参与闭环控制？允许的延迟是多少？对抖动是否敏感？

把这张通信地图建立起来之后，后续无论是配置 EtherCAT 从站、建立 OPC UA 信息模型，还是设计 MQTT 主题结构，都能先问一句：这个数据属于实时控制面还是数据协同面？边界清楚了，协议选型就不会错位，机器人协同的稳定性也就有了基础。