EtherCAT 从站通信延迟优化：从 2 个周期降低到 1 个周期的时序分析与实践-平芜编程栈

EtherCAT 从站通信延迟优化：从 2 个周期降低到 1 个周期的时序分析与实践

在 EtherCAT 系统里，我们经常会关注：

总线周期是多少；
PDO 有多大；
主站实时性怎么样；
DC 同步精度能做到多少。

但在实际做运动控制时，还有一个非常关键、却很容易被忽略的问题：

主站这一周期下发的数据，到底要过多久才能经过从站应用层处理，再反馈回主站？

这次项目中遇到的问题就是：

EtherCAT 周期 = T 主站第 N 周期下发命令 ↓ 从站处理 ↓ 主站直到 N+2 周期 才能看到对应反馈

也就是说，端到端存在：

2T

的周期级延迟。

进一步测试发现：

SM 模式：2 个周期 DC 模式：2 个周期

说明问题并不在 EtherCAT DC 本身，而在从站内部的 PDO 数据处理链路。

最终通过重新拆分从站应用层的数据处理流程，将通信延迟从：

2T

降低到了：

1T

这篇文章记录整个测试、分析和优化过程。

1. 先定义一下这里说的“通信延迟”

这里说的通信延迟，并不是：

EtherCAT Frame 从主站网口发出去 ↓ 到达从站 PHY

这种纯粹的物理层或链路层传播延迟。

真正关心的是：

主站某一周期发送一个新的控制量，从站接收到并经过应用逻辑处理以后，再把对应结果反馈回来，主站需要等待几个控制周期。

也就是：

Master │ │ RxPDO ▼ ESC │ ▼ Application │ ▼ Control / FOC │ ▼ Application │ ▼ ESC │ │ TxPDO ▼ Master

这是一个真正的：

端到端控制链路延迟。

对于 1 kHz 控制系统：

1 Cycle = 1 ms

那么：

2 Cycle = 2 ms

和：

1 Cycle = 1 ms

的差别其实已经非常明显。

对于机器人运动控制来说，这种周期级延迟甚至比几十微秒的总线传输时间更加值得关注。

2. 如何测量这种延迟？

为了避免凭感觉判断，我在 PDO 中专门增加了一个：

frameNum

用于做周期延迟测试。

主站每发送一帧：

frameNum++;

然后通过 RxPDO 下发给从站。

从站收到后，在 FOC 相关处理路径中将它保存下来：

RxPDO frameNum ↓ tempFrameNum

之后再把：

tempFrameNum

写入 TxPDO 返回给主站。

整个测试链路：

Master │ │ frameNum = N ▼ RxPDO │ ▼ Slave │ │ tempFrameNum = N ▼ TxPDO │ ▼ Master

如果在同一个 EtherCAT 报文周期中看到：

Master Send：N Slave Return：N - 1

说明：

延迟 = 1 Cycle

如果看到：

Master Send：N Slave Return：N - 2

则说明：

延迟 = 2 Cycle

这种办法非常简单，但很实用。

它的好处是：

不依赖 CPU 时间戳，也不依赖主从两边时钟同步，直接通过数据本身判断跨了多少个控制周期。

3. 优化前：SM 模式存在 2 个周期延迟

首先测试 SM 同步模式。

Wireshark 抓包看到：

主站发送： frameNum = 0x2609

而同一时刻从站反馈：

frameNum = 0x2607

两者相差：

0x2609 - 0x2607 = 2

因此：

SM 模式延迟 = 2 Cycle

如果控制周期为 1 ms：

2 Cycle ≈ 2 ms

当然，这里的“2 ms”是周期意义上的延迟，不等同于每一次都恰好固定为物理时间 2.000 ms。

更准确地说：

当前反馈数据落后于当前控制命令两个 EtherCAT 周期。

4. DC 模式同样存在 2 个周期延迟

接下来切换到 EtherCAT DC 模式。

抓包结果：

Master Send： frameNum = 0x069D

从站返回：

frameNum = 0x069B

仍然相差：

因此：

DC 模式延迟 = 2 Cycle

到这里实际上可以排除一个很容易出现的误区：

开启 DC 并不会自动降低 PDO 端到端延迟。

DC 主要解决的是：

时钟同步 SYNC0 / SYNC1 相位同步 多轴执行时刻同步

而这里的问题是：

PDO 数据什么时候被应用层读取 控制算法什么时候使用它 新的反馈什么时候重新写进 ESC

这是另一条链路。

所以：

SM → 2T DC → 2T

反而说明应该把排查重点放到：

Slave Application Data Path

上。

5. 优化目标

目标很明确：

优化前： Master Send N ↓ Slave ↓ Master Receive N-2

希望变成：

优化后： Master Send N ↓ Slave ↓ Master Receive N-1

即：

2 Cycle ↓ 1 Cycle

同时要求：

SM 模式有效 DC 模式同样有效

这意味着不能只针对某一种同步模式“打补丁”，而要真正梳理从站内部 PDO 的数据路径。

6. 从站内部真正参与通信的三个关键函数

继续分析 SSC 应用层代码以后，发现这个延迟主要和三个函数有关。

6.1`APPL_OutputMapping()`

voidAPPL_OutputMapping(UINT16*pData)

它负责：

ESC Process RAM ↓ RxPDO ↓ Outputt

也就是说：

把主站写入 ESC 的 Output Process Data，搬到 MCU 应用层变量中。

可以理解成：

EtherCAT 世界 ↓ Application 世界

之间的入口。

6.2`MotorDriver()`

原来的：

MotorDriver();

其实同时做了两类完全不同的事情。

第一类：

Outputt ↓ FOC 控制参数

也就是消费主站命令。

第二类：

FOC 实时状态 ↓ Inputt

也就是生成即将返回给主站的反馈数据。

因此原函数实际上把：

EtherCAT RxPDO → Control

和：

Control → EtherCAT TxPDO

两个方向的数据处理混在了一起。

6.3`APPL_InputMapping()`

voidAPPL_InputMapping(UINT16*pData)

负责：

Inputt ↓ TxPDO ↓ ESC Process RAM

最终主站下一次进行 EtherCAT 数据交换时，就能拿到这份数据。

所以完整链路其实是：

Master RxPDO ↓ ESC RAM ↓ APPL_OutputMapping() ↓ Outputt ↓ MotorDriver() ↓ FOC ↓ Inputt ↓ APPL_InputMapping() ↓ ESC RAM ↓ Master TxPDO

一旦把这条链路画出来，问题就开始变得清晰了。

7. SM 模式下的数据处理时序

先看 SM 模式。

原来的执行顺序可以简化为：

PDI IRQ │ ▼ APPL_OutputMapping() │ ▼ MotorDriver() │ ▼ APPL_InputMapping()

也就是：

ESC RxPDO ↓ OutputMapping ↓ Application ↓ InputMapping ↓ ESC TxPDO

乍一看，这个顺序似乎完全合理。

甚至很容易产生一种直觉：

既然三个函数都在一次 PDI 中断里执行，那么主站刚写进来的数据应该可以立刻处理，再马上反馈回去。

但真正的问题在于：

MotorDriver()

中的反馈数据并不只是由本次：

Outputt

简单计算得到。

其中很多反馈量来自：

FOC 周期 实时状态 传感器结果 控制器输出

也就是说：

收到 RxPDO

和：

对应控制结果真正产生

在时间上并不是完全同一个事件。

8. DC 模式下的数据路径更容易暴露这个问题

DC 模式的执行逻辑和 SM 不完全一样。

原工程中：

PDI IRQ ↓ APPL_OutputMapping()

而：

SYNC0 IRQ ↓ MotorDriver() ↓ APPL_InputMapping()

也就是说：

EtherCAT 数据到达 ↓ PDI IRQ ↓ OutputMapping │ │ 等待 SYNC0 ▼ SYNC0 IRQ ↓ Application ↓ InputMapping

这里已经能够非常明显地看到：

数据搬运和控制任务之间存在明确的时间边界。

而且 TxPDO 什么时候写回 ESC，很大程度上取决于：

APPL_InputMapping()

到底是在什么时刻执行。

9. 问题的本质：不是 EtherCAT 慢，而是“数据更新晚了一拍”

这是整个问题里最重要的一点。

抓包看到：

N ↓ N - 2

第一反应很容易是：

是不是 EtherCAT 带宽不够？ 是不是主站 1 kHz 太快？ 是不是 DC 有额外延迟？ 是不是 ESC 三缓冲导致的？

但沿着数据路径分析以后发现：

真正导致额外一个周期的，并不是帧在网线上多跑了一圈，而是 TxPDO 使用的数据在从站应用层晚更新了一个周期。

也就是说：

Physical Communication Latency

和：

Application Data Age

必须区分开来。

主站收到一帧 EtherCAT 报文，只能说明：

报文到了

但不代表里面的数据一定是：

当前周期刚刚计算出来的最新值

它可能已经是：

N - 1 N - 2

甚至更早的状态。

这就是很多实时通信系统里真正需要关注的：

Data Freshness，数据新鲜度。

10. 原来的函数设计存在什么问题？

原来：

MotorDriver();

同时负责：

方向 A： EtherCAT → FOC

和：

方向 B： FOC → EtherCAT

从软件结构上看：

RASA_motordriver_ETG │ ┌────────┴────────┐ ▼ ▼ Update Control Update Feedback Parameters Data

这两个动作其实具有完全不同的时间语义。

比如：

EtherCAT → FOC

希望尽可能靠近：

APPL_OutputMapping()

因为刚收到主站的新命令，应该尽快让控制算法看到。

而：

FOC → EtherCAT

希望尽可能靠近：

APPL_InputMapping()

因为在真正把 TxPDO 提交给 ESC 之前，希望采集最新的控制状态。

这两个方向被放进同一个函数以后，就失去了分别调整执行位置的能力。

11. 优化方案：把双向数据更新彻底拆开

因此最终做的关键修改其实非常简单。

原来的：

MotorDriver();

拆成两个函数：

updateEcatOutputData();updateEcatInputData();

两者职责完全不同。

11.1`updateEcatOutputData()`

负责：

Outputt ↓ FOC / Control Parameters

也就是：

把主站最新下发的 EtherCAT 命令同步到控制算法使用的数据区。

可以理解成：

EtherCAT → Control

11.2`updateEcatInputData()`

负责：

FOC / System State ↓ Inputt

即：

在准备上传 TxPDO 之前，把控制系统最新状态刷新到 EtherCAT Input 数据区。

可以理解成：

Control → EtherCAT

12. 拆函数的真正意义不是“代码更漂亮”

如果只是从软件工程角度看，这次修改好像只是：

一个大函数 ↓ 两个小函数

似乎只是一次普通重构。

实际上并不是。

真正的价值是：

拆开以后，可以分别决定 Rx 数据什么时候进入控制算法，以及最新控制状态什么时候进入 TxPDO。

也就是从：

Function Coupling

变成了：

Timing Control

这类实时系统中的函数拆分，很多时候并不是为了：

代码复用

而是为了：

精确控制代码运行时刻

这一点在 EtherCAT、FOC、实时中断系统里非常重要。

13. SM 模式优化后的处理链路

优化以后，SM 模式的数据路径变得更加明确。

核心思想：

收到主站命令 ↓ 立即更新控制参数 准备返回 TxPDO ↓ 尽可能更新最新反馈

可以理解为：

PDI IRQ │ ▼ APPL_OutputMapping() │ ▼ updateEcatOutputData() │ │ │ 控制系统运行 │ ▼ updateEcatInputData() │ ▼ APPL_InputMapping()

这样：

Output Path

和：

Input Path

在代码结构上已经完全解耦。

主站新命令一旦通过：

APPL_OutputMapping()

进入Outputt，马上就可以：

updateEcatOutputData()

让控制算法看到。

而在 TxPDO 真正写入 ESC 之前：

updateEcatInputData()

会尽量刷新最新的控制反馈。

14. DC 模式优化后的处理链路

DC 模式下同样按照这一思路处理。

PDI 中断：

PDI IRQ │ ▼ APPL_OutputMapping() │ ▼ updateEcatOutputData()

也就是：

EtherCAT RxPDO 到达 ↓ 立即更新控制参数

SYNC0 到来以后：

SYNC0 │ ▼ Control / FOC │ ▼ updateEcatInputData() │ ▼ APPL_InputMapping()

这样做以后：

RxPDO

和：

TxPDO

各自都尽可能靠近真正需要它的时间点。

整个数据链路变成：

Master │ │ RxPDO ▼ ESC RAM │ ▼ APPL_OutputMapping │ ▼ updateEcatOutputData │ ▼ FOC │ ▼ updateEcatInputData │ ▼ APPL_InputMapping │ ▼ ESC RAM │ │ TxPDO ▼ Master

相比原来：

Output + Input 全部绑在 RASA_motordriver_ETG

现在数据流更加清晰。

15. 从实时系统角度看，这实际上是在缩短“数据年龄”

可以引入一个很有用的概念：

Age of Data

假设主站在：

t0

下发命令：

Command[N]

如果从站到：

t0 + 1T

才真正让控制算法使用它，那么这份数据在进入控制算法时已经：

1T old

同理。

如果控制系统最新状态已经产生，但：

Inputt

直到下一周期才更新，那么主站最终拿到的状态同样是：

stale data

所以这次优化的本质可以概括为：

减少额外 Buffer / Stage ↓ 缩短 Data Age ↓ 降低 End-to-End Latency

这和单纯提高：

EtherCAT Bus Rate

不是同一类优化。

16. 为什么没有办法做到真正的“0 周期延迟”？

优化完成后：

Master Send N Master Receive N - 1

也就是：

1 Cycle Latency

有人可能会继续问：

为什么不能这一帧发送 N，这一帧同时收到 N？

对于周期性交换的主从闭环系统来说，这通常并不现实。

因为必须经过：

Master Send N ↓ Slave Receive N ↓ Slave Application Process ↓ Generate Feedback N ↓ Master Next Exchange ↓ Receive Feedback N

至少要经历：

一个 causality boundary

也就是说：

结果必须在原因发生之后产生。

所以在这种软件架构下：

1 Cycle

已经非常接近合理的最小周期级端到端延迟。

当然，EtherCAT 的 ESC 可以实现非常低的 on-the-fly forwarding latency，但那是：

Frame Forwarding

层面的能力。

和：

Master Command → Slave Application → FOC → Feedback → Master

这一整套闭环应用延迟完全不是一回事。

17. SM 模式优化后测试结果

优化完成后重新抓包。

主站当前下发：

frameNum = 0x15F2

主站收到的从站反馈：

frameNum = 0x15F1

两者相差：

因此：

SM Mode 2 Cycle ↓ 1 Cycle

达到了优化目标。

18. DC 模式优化后测试结果

再测试 DC 模式。

主站发送：

frameNum = 0x0649

从站返回：

frameNum = 0x0648

同样相差：

因此：

DC Mode 2 Cycle ↓ 1 Cycle

同样符合预期。

最终：

优化前 优化后 SM Mode 2T 1T DC Mode 2T 1T

证明这次优化解决的是：

Slave Application Data Path

而不是某一种同步模式下的特殊问题。

19. 为什么这个结果比单纯“减少 1 ms”更重要？

假设控制周期：

T = 1 ms

表面看：

2 ms ↓ 1 ms

好像只是减少了：

1 ms

但在闭环控制系统中，这个 1 ms 会进入整个控制链。

例如：

Robot Controller ↓ EtherCAT ↓ Joint Controller ↓ Motor ↓ Sensor ↓ EtherCAT ↓ Robot Controller

通信延迟本质上相当于控制环路中的：

Transport Delay

而纯延迟会直接带来：

Phase Lag

对于频率为：

的信号，时间延迟：

Td

对应的相位滞后近似为：

φ = -2πfTd

换成角度：

φ = -360° × f × Td

例如：

f = 50 Hz

如果：

Td = 2 ms

相位滞后约：

-36°

而如果：

Td = 1 ms

则约为：

-18°

所以：

在高动态控制系统里，一个 EtherCAT 周期的延迟并不是一个可以随便忽略的小量。

尤其随着整机控制带宽提高，这种影响会越来越明显。

20. 通信周期高，不等于系统延迟低

这次优化也让我重新认识了一个问题。

很多人评价一套实时通信方案，会首先看：

1 kHz 2 kHz 4 kHz

好像通信频率越高：

Latency

就一定越低。

其实并不完全成立。

比如两个系统：

System A： 2 kHz EtherCAT 2 Cycle Application Delay

那么周期：

T = 0.5 ms

应用延迟：

1 ms

另一个：

System B： 1 kHz EtherCAT 1 Cycle Application Delay

周期：

T = 1 ms

应用延迟同样：

1 ms

所以真正应该关注的是：

Control Frequency + Cycle Jitter + End-to-End Latency + Data Age

而不是只看：

Cycle Rate

21. 从这次问题可以抽象出一个通用排查方法

以后再遇到：

实时通信延迟过大

我会优先画一张：

Data Flow Diagram

把数据真正经过的每个阶段全部列出来。

例如：

Master App ↓ Master PDO ↓ EtherCAT Frame ↓ Slave ESC ↓ Output Mapping ↓ Application Buffer ↓ Control Task ↓ Feedback Buffer ↓ Input Mapping ↓ Slave ESC ↓ EtherCAT Frame ↓ Master PDO ↓ Master App

然后对每一个边界问：

这里有没有跨周期？ 这里有没有旧缓存？ 这里的数据什么时候刷新？ 这里消费的是当前值还是上一周期值？ 这里会不会等待另一个中断？ 这里是不是存在 double / triple buffer？ 这里生产者和消费者是否处于不同执行上下文？

这样通常比直接：

抓 Wireshark ↓ 看到慢 ↓ 怀疑 EtherCAT

有效得多。

22. 一个非常重要的原则：不要只测“通信”，要测“数据链路”

Wireshark 能够告诉我们：

Frame 什么时候出去 什么时候回来

但是它看不到从站 MCU 内部：

OutputMapping Application FOC InputMapping

到底经历了什么。

所以真正完整的实时通信延迟测试最好分层。

Level 1：Network Latency

测：

EtherCAT Frame

关注：

报文周期 WKC Frame Lost 传播时间

Level 2：PDO Latency

加入：

frameNum

关注：

Master Send N Slave Return N-k

从而测出：

k Cycle Latency

Level 3：Application Latency

用 GPIO 或硬件时间戳测：

RxPDO 到达 ↓ 控制任务开始

以及：

控制任务完成 ↓ TxPDO 生效

Level 4：Control End-to-End Latency

最终测：

Master Command ↓ Motor Torque / Position Response ↓ Master Feedback

这才是整个机器人系统真正关心的延迟。

23. 如果继续优化，还可以做什么？

这次已经从：

2T

降低到：

1T

继续往下优化，就不应该只盯着 PDO Mapping。

还可以进一步测量整个周期内部的时间预算。

例如：

1 ms Cycle ┌──────────────────────────────────────────────┐ │ │ │ Linux Wakeup │ │ ↓ │ │ EtherCAT Receive │ │ ↓ │ │ Master Control Algorithm │ │ ↓ │ │ EtherCAT Send │ │ ↓ │ │ Slave PDI IRQ │ │ ↓ │ │ Output Mapping │ │ ↓ │ │ Control / FOC │ │ ↓ │ │ Input Mapping │ │ │ └──────────────────────────────────────────────┘

可以分别记录：

T_master_jitter T_frame T_pdi T_mapping T_control T_feedback

最终建立：

Latency Budget

这样后续再优化时，就可以知道：

时间到底花在哪里，而不是盲目把所有代码都继续“加速”。

24. 这次优化给我的几个启发

24.1 延迟问题首先看数据路径，不要首先看总线

EtherCAT 本身可能很快。

真正慢的可能是：

Buffer Task ISR Mapping Control Loop

因此：

Communication Problem

并不一定发生在：

Communication Bus

上。

24.2 “函数在哪运行”往往比“函数运行多久”更重要

这次：

MotorDriver()

本身并不一定耗时很多。

真正的问题是：

它什么时候运行

以及：

它里面的不同数据处理为什么必须绑在同一时刻运行

在实时系统中，经常存在：

Execution Time：20 us

并不危险。

但：

Execution Phase：晚 1 个周期

却可能直接产生：

1 ms latency

所以性能优化不能只看：

CPU Cost

还要看：

Scheduling Phase

24.3 实时系统中的函数拆分，本质上经常是时序拆分

普通应用开发里，把函数拆开可能主要为了：

可读性 单一职责 代码复用

而实时控制系统中，还有一个更重要的原因：

让不同逻辑能够在不同时间点执行

这次：

updateEcatOutputData()

和：

updateEcatInputData()

拆开以后，真正得到的是：

Timing Freedom

而不只是：

Cleaner Code

24.4 frame counter 是非常实用的实时通信诊断手段

这次只加了一个：

frameNum

就很直观地发现了：

N → N-2

而优化以后：

N → N-1

除了通信延迟之外，这种序号机制还可以继续用于检测：

丢帧 重复帧 乱序 周期跳变 数据停滞 从站处理卡顿

例如：

if(frame_num!=last_frame_num+1){communication_error++;}

所以在设计实时通信协议时，我现在比较倾向于专门保留：

Sequence Counter

哪怕只占：

16 bit

通常都非常值得。

25. 总结

这次问题最开始看到的现象很简单：

Master Send N ↓ Slave Return N-2

无论：

SM Mode

还是：

DC Mode

都存在两个周期的端到端延迟。

最终沿着数据路径分析：

ESC RxPDO ↓ APPL_OutputMapping ↓ MotorDriver ↓ FOC ↓ MotorDriver ↓ APPL_InputMapping ↓ ESC TxPDO

发现问题并不在 EtherCAT 总线本身，而在从站应用层的数据更新时序。

最终将：

MotorDriver();

拆分为：

updateEcatOutputData();updateEcatInputData();

分别负责：

EtherCAT → Control

和：

Control → EtherCAT

再根据 SM / DC 的实际执行时序重新安排调用位置。

优化完成以后：

Before After SM 2T 1T DC 2T 1T

如果控制周期为：

T = 1 ms

就相当于端到端数据链路减少了约：

1 个控制周期

这次优化让我印象比较深的一点是：

实时通信系统里的“延迟”，很多时候并不是数据在线缆上传输了多久，而是数据在软件系统中等了多久。

真正想降低端到端延迟，不能只研究 EtherCAT 带宽、周期和 PHY，还要继续往从站内部看：

什么时候收到数据？ 什么时候把数据交给控制算法？ 什么时候产生新的反馈？ 什么时候写回 Process RAM？ 主站下一次拿到的到底是哪一周期的数据？

把这些问题回答清楚以后，很多看起来像“通信性能”的问题，最后其实都是一个：

数据流与执行时序设计问题。