4. EtherCAT主站软件架构与实时性设计

EtherCAT 的从站通信由 ESC 硬件完成,主站却完全运行在通用 CPU 上。这意味着主站软件必须自己承担报文组装、周期调度、过程数据交换和状态机管理,而它的实时性直接决定了机器人关节能否在确定的时间点拿到新的目标值。理解主站软件架构,本质上就是理解"一个非实时操作系统上的普通进程,如何变成一台确定性的运动控制器"。

主站协议栈的分层结构

典型 EtherCAT 主站(如 IgH EtherCAT Master、SOEM、TwinCAT、Acontis)在结构上可分为四层。最底层是网卡驱动与链路层,它绕过内核网络协议栈,直接操作以太网控制器发送原始 EtherCAT 帧;其上是主站核心,负责扫描从站、配置 FMMU/SyncManager、维护过程数据映像(Process Data Image)和邮箱通信;再往上是周期性过程数据接口,把分散在各从站的过程数据映射成一块连续内存,供上层读写;最上层是应用层,即机器人控制器中的轨迹插补、伺服使能、状态机与安全逻辑。

关键点在于:主站核心与网卡驱动之间通常通过内核模块或实时驱动交互,而应用层可能运行在用户态。如果应用层与过程数据映像之间隔着一次系统调用或内存拷贝,抖动就会显著增加。因此高性能主站往往把过程数据映像直接映射到用户态共享内存,让应用任务以指针方式读写,避免每周期复制。

EtherCAT 主站软件分层与实时数据通路 应用层(用户态) 轨迹插补 · 伺服使能 · 状态机 · 安全逻辑 · 机器人控制周期任务 周期任务 T = 1 ms 过程数据映像(Process Data Image) 连续共享内存 · 输入区(从站→主站) · 输出区(主站→从站) · 指针直接读写 主站核心(内核模块 / 实时驱动) 从站扫描 · FMMU/SyncManager 配置 · 邮箱通信 · 过程数据映射 · 状态机管理 网卡驱动与链路层 绕过内核网络协议栈 · 直接发送原始 EtherCAT 帧 · 硬件时间戳 EtherCAT 从站(ESC 硬件) 抖动敏感点 系统调用 / 内存拷贝 → 共享内存直映射 周 期 触 发

实时操作系统与任务调度

主站要保证 1 ms 甚至 250 μs 的周期,必须依赖实时操作系统(RTOS)或实时补丁。常见方案有三类:一是 Linux + PREEMPT_RT 补丁,把内核中大部分不可抢占区域改为可抢占,使最坏中断延迟降到几十微秒;二是 Xenomai 双内核,在 Linux 旁挂一个实时微内核,实时任务运行在微内核上;三是直接在 VxWorks、QNX 等硬实时系统上运行主站。

调度策略上,EtherCAT 周期任务通常采用固定优先级抢占式调度。周期任务优先级最高,邮箱处理、日志、非周期诊断等任务优先级依次降低。周期任务内部一般按"等待同步信号 → 读取输入映像 → 执行控制算法 → 写入输出映像 → 触发报文发送"的顺序执行。其中"等待同步信号"通常由 DC(Distributed Clocks)提供的 SYNC0 中断或高精度定时器触发,而不是由软件延时轮询,否则周期起点会随负载漂移。

一个容易被忽视的细节是:控制算法本身必须可预测。如果周期任务中调用了动态内存分配、文件 I/O、锁竞争或未限定迭代次数的循环,即使平均执行时间很短,最坏执行时间也可能超出周期。因此实时任务中应使用预分配缓冲区、无锁队列和固定迭代次数的算法。

抖动来源与控制方法

抖动(Jitter)指实际周期与理想周期之间的偏差。对机器人而言,抖动会直接转化为关节速度波动,在力控或视觉伺服中尤其敏感。主要来源包括:

  • 中断延迟:网卡中断被其他中断或内核临界区阻塞,导致报文收发推迟。
  • 调度延迟:高优先级任务就绪后,因内核不可抢占而无法立即切换。
  • 缓存与内存访问:过程数据映像若未锁定在内存中,可能触发缺页或缓存抖动。
  • CPU 频率调节:节能调频导致执行时间不稳定,应关闭 C-state 和频率缩放。
  • 网络栈干扰:普通以太网流量、ARP、DHCP 等会占用网卡和 CPU,应隔离专用网口。

控制方法上,工程中常采用:将 EtherCAT 网口与系统其他网络物理隔离;把周期任务绑定到独立 CPU 核(CPU 亲和性);关闭该核上的中断均衡和内核线程;使用 DC 同步让所有从站与主站时钟对齐;在应用层用示波器或主站自带统计接口观察周期时间直方图,确认最坏值是否在允许范围内。

与机器人控制周期的匹配

机器人控制周期通常为 1 ms、500 μs 或 250 μs,而 EtherCAT 通信周期可以与之相同,也可以成整数倍关系。常见做法是让 EtherCAT 周期等于控制周期,使每个控制周期都能刷新一次过程数据。若控制周期为 1 ms,EtherCAT 周期也设为 1 ms,则主站每 1 ms 发送一次过程数据帧,从站收到后立即更新输出,并在下一个周期把输入回传。

需要区分两个时间概念:通信周期是主站发送报文的间隔;控制周期是应用层计算新目标值的间隔。二者可以相同,也可以让通信周期小于控制周期,例如通信 250 μs、控制 1 ms,这样每个控制周期内过程数据被刷新四次,输入采样更细,但主站负载更高。选择时应根据伺服带宽、关节数量和总线负载综合权衡。

判断周期匹配是否合理,可以观察三个量:主站周期时间的最坏值是否小于周期的 80%;从站 DC 同步偏差是否稳定在微秒级;机器人关节在低速运行时是否出现可感知的爬行或抖动。若最坏值接近周期上限,应优先排查中断延迟和 CPU 隔离,而不是盲目提高 CPU 主频。

一个可参考的周期配置示例

假设一台六轴机器人,伺服驱动支持 1 ms 周期,主站运行在 Linux + PREEMPT_RT 上,配置如下:

控制周期:        1000 μs
EtherCAT 周期:   1000 μs
DC 同步模式:     SYNC0,周期 1000 μs,偏移 200 μs
周期任务优先级:  90(最高)
CPU 亲和性:      CPU 2(isolcpus=2)
过程数据映像:    预分配共享内存,mlockall 锁定
网卡:            专用千兆网口,关闭中断合并

在该配置下,主站周期任务在 SYNC0 中断后启动,读取输入映像、执行逆解与伺服使能逻辑、写入输出映像,然后触发报文发送。若实测最坏周期时间为 720 μs,则留有约 28% 余量,属于可接受范围;若最坏值达到 950 μs,则应检查是否有其他任务抢占 CPU 2,或网卡中断是否被迁移到了该核。

主站软件架构与实时性设计不是一次配置就能定型的,它需要结合具体机器人、伺服和操作系统反复测量与调整。理解分层结构、调度机制和抖动来源,才能在出现周期超时或关节抖动时快速定位到正确的层面,而不是在应用代码里反复修改参数。