摘要：我们之前写过一篇《单轴运行很稳定，一增加到四轴就开始超时》，后台收到的问题集中在同一个地方——"超时"两个字背后，是一条从来没被算清楚的账。这篇把它算清楚：1ms 的 EtherCAT 周期里到底装了什么、32 个关节占多少、什么时候 1ms 会不够用、不够用了有哪些解法，以及人形机器人的总线到底该选 EtherCAT、CAN FD 还是以太网。文里有一句可以背下来的公式：100Mbps 下，每字节 80ns。

---

一、从"单轴稳定、四轴超时"说起

先说一个我们反复遇到的现象：EtherCAT 系统在单轴、双轴上跑得好好的，轴数加到四轴、八轴就开始出现周期超时；换成 32 轴的人形关节，同样的代码、同样的配置，问题变本加厉。

很多人的第一反应是"网络不稳定"“换个网线试试”“从站质量问题”。但绝大多数时候，问题的根不在设备，而在预算：1ms 的周期是一个固定大小的容器，报文、转发、主站处理、控制计算都要往里装，轴数一多，容器被装满了而已。

单轴的时候装得下，不代表四轴装得下；四轴装得下，不代表 32 轴装得下。这条账必须每个项目自己算一遍，因为变量全在你的系统里：轴数、PDO 长度、主站实现、拓扑结构。

这篇文章就干一件事：把这条账拆开，算给你看。

二、1ms 里装了什么：周期预算的四个组成部分

2.1 先理解一条 EtherCAT 报文的旅程

EtherCAT 的核心机制是"on-the-fly"（数据边传边处理）：主站发出一条（或几条）以太网帧，帧沿着逻辑环依次经过每个从站；每个从站用硬件（ESC）在帧经过的瞬间读取自己的输出数据、写入自己的输入数据，然后立刻转发，不做停顿。帧走完一圈回到主站，主站拿到所有从站的反馈，计算出下一周期的指令，再发下一帧。

所以一个周期的实际构成是：发帧 → 帧走环 → 收帧 → 计算 → 准备下一帧。 这四步里的每一步都有耗时，加起来必须小于周期时间，还要留余量。

2.2 第一部分：报文串行化时间——最大的头

帧在 100Mbps 的线路上传输，每一位占 10ns，也就是：

每字节 80ns。 这句话建议直接背下来。

按这个公式：1KB 的报文（含帧头、EtherCAT 头、CRC、帧间隙）大约 80µs 的串行化时间。这不是"网络延迟"，是物理传输时间——光速级别的物理约束，改协议改不掉，只能靠减少字节数或提高速率。

一个 32 轴的伺服环，典型 PDO 配置是每轴约 32 字节（控制字、目标位置、目标速度、模式出去；状态字、实际位置、实际速度、力矩回来），32 轴正好约 1KB——80µs 的串行化时间，这是 1ms 周期里第一笔、也是最大的一笔固定开销。

2.3 第二部分：从站转发与线缆传播

每个从站转发一帧的硬件延迟通常在 0.6–1µs（取决于 ESC 型号）。32 个从站串起来，就是 20–30µs。线缆传播延迟约 5ns/米，机器人身上几米的线束可以忽略不计；但如果你为了布局加了长长的拖链线缆，或者拓扑里插了分支耦合器（每个耦合器也有转发延迟），这笔账要单独加上。

2.4 第三部分：主站栈与调度

这一部分差异最大，也最容易被低估：帧的组装、发送、接收、PDO 映射、数据拷贝到控制应用、再把新指令拷回来——全部发生在主站侧。工程实践中，一个做了核心隔离和实时调度优化的主站，这部分通常可以压到 几十µs；而跑在普通 Linux、没有隔离、还要跨进程拷贝数据的实现，几百µs 也很常见。

所以这一项与其记一个数字，不如记住它的区间和量级：几十到几百µs，取决于实现。在自己的项目上，可以用一个很简单的办法估算：在发帧和收帧处各打一个时间戳（TSC 或 CLOCK_MONOTONIC），跑 30 分钟看 P99.9 和 max——再次强调，别看平均值。这样得到的数字，比任何文章里的区间都更有价值。

2.5 第四部分：DC 同步窗口

这里有一个关键认知，值得单独说：在 EtherCAT 里，“数据到达各从站的时间不同"并不重要，重要的是"所有从站同时执行”。 帧经过 32 个从站要 20–30µs，第一个和最后一个从站拿到数据差了近 30µs——如果各干各的，多轴同步直接就崩了。

分布式时钟（DC）解决的就是这件事：主站通过测量各从站的时钟偏差，把它们对齐到同一个时间基准；每个周期，所有从站等到同一个 SYNC0 时刻，再同时把新的指令应用到伺服环。实测中，DC 的同步抖动可以做到 1µs 量级（我们在《开源EtherCAT主站方案-最大抖动低至1微秒》里公开过这组数据）。

所以 DC 窗口不是"开销"，是"对齐成本"——它把 30µs 的到达时间差异，压缩到了 1µs 的输出同步精度。这笔买卖是整个 EtherCAT 设计里最划算的一笔。

2.6 合起来：32 轴 1kHz 的预算表

把四部分装进 1ms，得到这样一张表（数值为工程经验区间与公开资料量级，用于建立量级判断，具体项目以自测为准）：

组成部分	典型量级（32 轴）	说明
报文串行化	~80µs	1KB @100Mbps，每字节 80ns
从站转发	20–30µs	32 × 0.6–1µs，加耦合器另算
主站收发与栈处理	50–150µs	工程经验区间，因实现而异
控制计算	100–300µs	全身控制/轨迹生成，按 Vol.02 的预算表
DC 窗口与抖动	1–10µs	同步精度公开实测约 1µs
余量	≥30%	不允许为零

合计大约 300–600µs。结论：32 轴、1kHz、100Mbps 的 EtherCAT，1ms 的周期是够的，但已经不宽裕了——余量只剩一半左右，而且这是在 PDO 精简、主站确定的前提下。任何一个变量恶化（轴数再涨、PDO 变重、主站没优化），余量就会被吃掉。

这也解释了"单轴稳定、四轴超时"的另一种常见情况：不是 EtherCAT 不行，是这台机器的余量本来就只有那么点，多两轴就现原形了。

三、什么时候 1ms 不够用

3.1 先学会算三笔账

第一笔，轴数账。报文大小 ≈ 每轴 PDO 字节数 × 轴数，串行化时间 = 字节数 × 80ns：

轴数	报文约	串行化时间
32 轴	1KB	~80µs
64 轴	2KB	~160µs
128 轴	4KB	~320µs

第二笔，频率账。周期缩短，不是所有开销都等比缩短——报文和转发时间不变，缩的是留给主站和计算的余量：

周期	对应频率	32 轴可行性
1ms	1kHz	可行，留 30%+ 余量
500µs	2kHz	临界：报文 80µs + 转发 25µs 已占 21%，主站和计算必须极优
250µs	4kHz	100Mbps 下不可行：光报文就占 32%，加上主站栈基本无解
125µs	8kHz	需要 EtherCAT G（千兆）或彻底重构拓扑

第三笔，载荷账。同样的 32 轴，多带一个 FSoE 安全报文、加上关节力矩与温度 PDO、再加上触觉传感器数据，报文可能从 1KB 涨到 1.5KB 甚至 2KB——串行化时间直接跟着涨 50% 到 100%。

3.2 五个"不够用"的信号

1. 轴数超过 64，且 PDO 没有精简——报文时间开始吃掉主站的处理窗口；
2. 控制环要求 4kHz 及以上——100Mbps 带宽物理上不允许 32 轴的 4kHz 全量报文；
3. PDO 变重——安全、力控、多传感器上线；
4. 拓扑复杂化——分支耦合器、长线缆、跨关节走线，每一跳都在加账；
5. 主站实现不确定——没有核心隔离、非实时调度、大量数据拷贝，“预算表上够，实际跑起来不够”。

3.3 不够用了怎么办：五个手段

手段一：减 PDO。 只传必要的对象，把诊断类、状态类数据从周期报文里挪出去（低频上报或事件触发）。这是最便宜、见效最快的一条。

手段二：解耦"总线频率"和"控制频率"。 DC 加伺服内部插值可以做到：总线 1kHz 下发位置指令，驱动器内部以 10–20kHz 插值执行。很多"4kHz 需求"其实是内环需求，不是总线需求——想清楚这一点，一半的带宽焦虑就消失了。

手段三：EtherCAT G（千兆）。 串行化时间直接除以 10：1KB 报文从 80µs 降到 8µs。代价是从站与主站硬件要支持千兆，生态还在完善。

手段四：双环分段。 双网口主站把 32 轴拆成两条环，报文并行传输——每条环 16 轴、512 字节，串行化时间减半，转发级数也减半。

手段五：主站确定性优化。 核心隔离、中断搬家、零拷贝、报文预组装——把第 2.4 节那笔"50–150µs"压到下限，等于白捡 100µs 的余量。

四、人形机器人该用 EtherCAT、CAN FD 还是以太网？

这是评论区被问得最多的问题，给一个尽量干脆的答案。

维度	EtherCAT	CAN FD	以太网 / TSN
速率	100Mbps（G 版 1Gbps）	仲裁段 1Mbps / 数据段 2–8Mbps	100M–1Gbps
32 轴 @1kHz	可行（预算见上）	不可能：单帧 64 字节约 120–200µs，32 轴远超 1ms	带宽够，确定性取决于 TSN 配置
同步精度	µs 级（DC）	无硬件同步，靠软件对齐	TSN 802.1AS 可到亚 µs
拓扑	环/线，需 ESC 硬件	总线，线束最简单	星/环，交换机构建
线束与成本	中	低	高（交换机、PHY）
适用定位	多轴、高频、高同步的运动控制	少轴、低频、辅助器件、传感器	大带宽、多传感器融合、未来路线

结论直接给：

• 20–40 个关节、1kHz 级控制、需要 µs 级同步——EtherCAT 是当前最成熟的选择，这也是为什么工业界和多数人形机器人的关节总线都选它；
• CAN FD 的位置在别处：少轴（4 轴以内）、低频、或者辅助器件（电池管理、灯光、慢速传感器）——它的价值是便宜、抗干扰、线束简单，不是跑 32 轴；
• 以太网/TSN 是未来方向，带宽和生态都有优势，但运动控制的确定性依赖 TSN 的精细配置，从站侧的实时支持还在成熟过程中——现在入场，要有趟坑的准备。

最后提醒一句：总线选择不是一个"技术先进性"问题，是一个"预算能不能被满足"问题。 先算账（轴数 × 周期 × 同步精度），再选路线，顺序反过来，就是给项目埋雷。

五、结论

把这篇压成一句话：

EtherCAT 的 1ms 够不够，取决于四笔账加一个余量——算得清楚就是够，算不清楚就是不够。

带走三个可以反复用的数字：100Mbps 下每字节 80ns；32 轴典型报文约1KB；预算必须留30% 余量。下次再遇到"轴数一多就超时"，先把这三句话拿出来算一遍，答案八成就在里面。

六、检查清单：EtherCAT 周期预算自查，八条

1. 先数字节。 把每轴 PDO 的实际长度列出来（用总线工具抓帧最准），乘以轴数，得到报文大小。
2. 用 80ns/字节 估串行化时间，再加上从站数量 × 1µs 的转发账。
3. 实测主站栈开销。 发帧/收帧打时间戳，跑 30 分钟看 P99.9/max，别用别人的数字。
4. 验证 DC 同步质量。 用示波器打两个从站的 SYNC0 和输出，确认同步抖动在实际负载下的量级。
5. 留够余量。 30% 是底线，PDO 还在长的项目要留更多。
6. 分辨需求层级。 "4kHz 需求"先问清楚是总线需求还是伺服内环需求，后者用插值解决。
7. 拓扑做减法。 分支耦合器和长线缆都是预算杀手，布局阶段就要算进账。
8. 形成预算表文档。 每新增一个从站、一组 PDO，更新预算表——这张表和 Vol.04 的抖动预算表一样，是项目的地基文档。

七、留一个问题给你

人形机器人的关节总线，你站哪条路线？

• 站 EtherCAT 的：成熟、确定、生态完整，先用好再说；
• 站 CAN FD 的：线束和成本优势在整机层面不可忽视，少轴方案够用；
• 站以太网/TSN 的：未来一定是融合，早入场早积累。

评论区说说你的选择和理由。下一篇，我们回到架构争论的主战场：《人形机器人：RTOS 双系统还是实时 Linux 单系统？》——这是账号历史上一篇 1,373 阅读的文章的具身智能升级版。

---