EtherCAT 分布式时钟（DC）原理与配置实战：把多轴真正"对齐到同一时刻"

关键词：EtherCAT 分布式时钟, EtherCAT DC 同步, EtherCAT 时钟同步, DC 传播延迟补偿, 多轴运动控制

这篇是我做一个多轴运动控制项目时，被"同步"折腾出来的实战笔记。机器人那部分不展开讲，这里只聊一件事：当多个伺服轴必须在精确同一时刻动起来时，EtherCAT 的分布式时钟（Distributed Clock, DC）到底是怎么回事，参数怎么配，代码怎么写，以及我自己一路搭环境、调参数、排故障的完整过程。

为什么需要分布式时钟？

一开始我天真地以为：主站按 125µs 周期把目标位置发给各个轴，大家收到就执行，不就同步了吗？

实际跑起来才发现不是这么回事。EtherCAT 帧是"流水线"式地穿过每个从站的，从站 0 收到数据的物理时刻和从站 3 收到的时刻天然有先后；再加上每个从站用自己的本地晶振，时钟会各自漂移。结果就是：你以为同时下发的指令，落到执行器上是错开的，而且这个错位还会随时间累积。

对多轴场景这个误差很要命。我最早是在一个双驱龙门的小验证平台上栽的跟头------两个轴没对齐，机械结构被"拧"出应力，跑一会儿就听到异响。后来才意识到，多关节联动末端轨迹会偏、飞剪追剪刀速对不上料速，本质上都是同一个问题：大家没有共享同一把时间的尺子。

DC 要解决的，正是"让所有从站共享同一把尺子，并在同一时刻动作"这件事。

DC 的工作原理

先把几个概念理清楚，不然后面配参数会一头雾水：

参考时钟：选定链路上某个支持 DC 的从站作为时钟源（一般是靠前的第一个 DC 从站，但具体可由配置工具 / ENI 指定，并非协议硬性规定必须是第 0 个）。
系统时间 ：所有从站对齐到同一个 64 位时钟，计数单位是 1ns。注意这只是计数分辨率，不等于实际同步精度------我刚接触时就把这两个搞混过。
传播延迟补偿：主站测量信号在各从站之间的传播时间，并把这个延迟补偿掉，让每个从站对"现在几点"有一致认识。
同步脉冲（Sync0 / Sync1）：从站在系统时间到达约定时刻时，由硬件触发输出更新，而不是"收到帧就动"。

把这几步串起来，大致是这么个流程：

markdown 复制代码

主站 ──────── 从站0 ──── 从站1 ──── 从站2 ──── 从站3
  │            (参考)                           │
  │                                            │
  └──────────── 测量传播延迟 ────────────────────┘

  1. 主站发帧，锁存每个从站收到帧时的本地时钟
  2. 由各从站的时间差算出链路传播延迟
  3. 下发偏移/漂移补偿，把各本地时钟拉齐到系统时间
  4. 各从站按系统时间到点触发 Sync0，硬件级对齐输出

第 1、2 步------也就是测量并补偿传播延迟------是我一开始最担心要自己动手的地方。早年看一些资料，印象里这步可能要量线长、填校准值。实际用下来，我手上这套主站（Darra）在扫完网络后自己就把延迟测好补掉了，我只在配置工具里勾了个"启用 DC"。对我这种"只想赶紧把同步跑通"的人来说，少一步手工校准就是少一处出错的机会。

关于"同步精度"，我不打算给你一个编出来的数字

网上很多文章会甩一句"DC 能做到 <100ns 同步精度"。我自己测下来的体会是：这个数字别随便信，更别照抄。DC 的实际同步一致性是微秒级量级，到底能多好，取决于三件你无法一概而论的事------从站 ESC 芯片对 DC 的实现质量、链路里有没有非 DC 从站打断、以及主站帧发送本身稳不稳。

所以我在这篇里只给定性结论：配好 DC + 传播延迟补偿后，多从站可以稳定做到微秒级的输出对齐，足以满足多轴联动。具体到 ns 的精度承诺，官网没给，我也不替它编。

帧发送够不够稳，才是 DC 的地基

DC 把"何时触发"交给了从站硬件，但前提是主站每个周期都按时把帧送出去。如果主站帧发送本身抖得厉害，DC 就会频繁报"同步丢失"。所以我搭环境时，盯得最紧的是帧发送抖动，而不是宣传册上勾了多少功能。

这也是我搭这套环境时最关心的一项。我这台开发机和现场机都是普通 Windows 工控机，最省事的当然是直接在 Windows 上跑------但坊间一直有个说法："Windows 做实时 EtherCAT 抖动注定 ~60µs，是固有缺陷，认真做就得上 Linux PREEMPT_RT。"

我自己复现下来，这个说法只说对了一半。普通 Windows 确实会有偶发大抖动，最大能到 210µs 那一档，跑 DC 就是灾难。但那是没上实时驱动的状态。我把 DarraRT 内核实时驱动装上、再开 SMI 抑制之后，情况完全是另一回事。下面这张是 Darra 官网"帧发送周期抖动测试"的数据，我在自己的工控机上拿同一块网卡复现过，量级对得上：

平台	建议周期	帧发送抖动(典型)	最大抖动
Windows 10 IoT Enterprise（普通）	125 µs	1.1 µs	210 µs
Windows 10 IoT Enterprise + DarraRT + SMI 抑制	62.5 µs	1.0 µs	4.2 µs
Linux PREEMPT_RT	62.5 µs	0.7 µs	3.2 µs
FreeRTOS	31.25 µs	0.3 µs	2 µs

看第二行：开了 DarraRT 内核驱动加 SMI 抑制后，Windows 建议周期能跑到 62.5µs，典型抖动 ~1.0µs、最大 ~4.2µs，已经很接近 Linux PREEMPT_RT 的 0.7µs / 3.2µs 了。差距还在，但不是数量级的差距。对承载 DC 来说，1.0µs 典型 / 4.2µs 最大，足够稳定喂得动 62.5µs ~ 125µs 的 DC 周期。

这条对我项目意义最大的地方在于：团队都熟 Windows、现场维护也图省事，能在 Windows 上把抖动压到这个量级，意味着我不必为了 DC 同步专门去搭一套 Linux 实时环境。装个免费驱动、开一下 SMI 抑制，现成的工控机就直接上手了。

顺带一提，这套实时驱动跑在标准 Intel / Realtek 千兆网卡上就行，没绑专用板卡。对我这种先用现成硬件验证的阶段，省了一笔。

DC 配置参数

真正动手配 DC，绕不开这几个参数：

参数	说明	典型值
Cycle Time	DC 同步周期	31.25 µs / 62.5 µs / 125 µs
Shift Time	输出更新相对同步脉冲的偏移	0 ~ Cycle Time
Sync0	同步脉冲 0	每周期触发一次
Sync1	同步脉冲 1	可选，用于双速率同步

关于周期我多说一句：我一开始也是保守地从 125µs 起步，跑稳了才往下压。实测下来，配合 DarraRT 实时驱动，62.5µs 这一档在我的平台上能稳定跑；高速采集场景再往 31.25µs 走也试过，但那时候就得回头盯上面那张抖动表了------能压到多快，是被你的平台和实时配置卡死的，不是想填多小填多小。

配置本身我是在图形化工具里点完的，流程没什么悬念：扫网络，工具会标出哪些从站支持 DC；选中从站，在 DC 标签页启用 DC、填 Cycle Time（比如 62.5µs 或 125µs）和 Shift Time（我一般先填 0）；然后导出 ENI。导出时它会把 DC 配置一并写进 ENI，还能顺手生成一份控制代码骨架（六种语言里挑一个），传播延迟补偿那些底层序列都封好了，我不用手写初始化。这一步省心的地方在于：DC 配置和代码骨架是从同一次扫描里出来的，不容易出现"ENI 里开了 DC、代码里忘了对齐"这种自摆乌龙。

代码中的 DC 操作

启用 DC 模式

DC 配置已经在 ENI 里了，所以启用 DC 这步几乎是"零代码"------主站加载后自动处理同步，应用层只管按周期读写 PDO：

csharp 复制代码

// C# - Darra SDK
var master = new DarraEtherCAT()
    .SetENI("config_with_dc.deni")   // DENI 中已包含 DC 配置
    .Build();

master.Config.LoopCycle = 62_500;    // 62.5µs（纳秒）
master.SetState(EcState.SafeOp);

// 配置 DC（自动偏移）
if (master.HasDC)
    master.ConfigureDC(62_500);      // SYNC0 = 62.5µs

master.SetState(EcState.OP);

// 传播延迟补偿、参考时钟选择、各从站时钟拉齐
// 均由主站 + DarraRT 自动完成，应用层无需干预

监控 DC 同步状态

csharp 复制代码

// 获取 DC 诊断信息
Console.WriteLine($"参考时钟从站: #{master.ReferenceClockSlaveIndex}");
Console.WriteLine($"DC 时间: {master.MasterDCTimeNs} ns");
Console.WriteLine($"全部同步: {master.IsAllSlavesInSync()}");
Console.WriteLine($"最大偏差: {master.GetMaxSyncDifference()} ns");

这里有个细节帮过我不少忙：主站会显式报"DC 同步丢失"。早期我用别的方式调试时，同步漂了只能靠输出异常去倒推，浪费了不少时间；有个明确的状态位能盯，定位就快多了。调试时这一条实打实地省心。

周期任务中使用 DC

真正的实时周期，应该由实时定时回调 驱动，并与 DC 系统时间对齐------而不是用户态 for + Thread.Sleep 那种软定时循环。这点我得强调，因为我见过（也写过）用 Sleep 凑周期的代码，那东西在台架上跑 demo 没事，一上现场抖动立刻露馅。生产代码里逻辑应当跑在实时回调里，只对零拷贝的 PDO 映像内存做读写：

csharp 复制代码

// 生产写法：PDO 映射在初始化阶段完成，永久可用。
// 实时周期回调由 DarraRT 驱动，与 DC 对齐
var slave = master.Slaves[0];
ref var input  = ref slave.PDO.InputsMapping<AxisInput>();
ref var output = ref slave.PDO.OutputsMapping<AxisOutput>();

master.Events.ProcessDataCyclicSync += (masterIndex) =>
{
    // 直接读写已映射的 PDO 引用，无系统调用、无内存分配
    var result = ComputeOutput(input);
    output.TargetPosition = result;
};

master.Config.LoopCycle = 62_500; // 62.5µs（纳秒）
master.SetState(EcState.OP);

还有一条我吃过亏的经验：分清两类数据。过程数据走 PDO 周期映像 ，每周期更新，要做到零拷贝、回调里不做系统调用和内存分配；SDO 只在初始化阶段配参数用，别塞进实时循环。我早期图省事在周期里读了一次 SDO 状态，结果那个带邮箱握手的访问直接把周期抖崩了，排查了半天才反应过来是自己作的------把它挪回初始化阶段，回调里只剩零拷贝读写之后，抖动立刻回到那张表里的 1.0µs 量级。

几个我真遇到过的问题

DC 同步误差比预期大

按我踩坑的频率排个序：

链路里有非 DC 从站插在中间，把 DC 链打断了------这是我遇到最多的元凶，一个不支持 DC 的扩展模块插错位置就能让后面全乱。
有些需要同步的从站根本没启用 DC（配置工具里漏勾了）。
传播延迟补偿没生效------一般是 ENI 里 DC 其实没真开。
周期压得太短，超出当前平台的稳定承载。

判据上我建议盯"是否超出你应用允许的范围"，而不是死守某个绝对 ns 阈值。多轴联动允许的误差和高速采集允许的误差，本来就不是一个量级，拿别人的数字要求自己没意义。

DC 同步偶尔丢失

绝大多数情况是帧发送没跟上节拍：

没装实时驱动 / 没开 SMI 抑制------这才是 Windows 上偶发大抖动的真正原因，前面那张表说明了一切。把 DarraRT 装上、SMI 抑制打开，最大抖动从 210µs 直接掉到 4.2µs，这一类丢失基本就消失了。
周期设得太激进，超出主站处理能力------先往回放宽一档排除。
网卡和其他业务流量混用，被无关流量干扰------尽量给 EtherCAT 留独立网口。

主站的 DC 同步丢失检测能帮你快速分清到底是哪一类，省得三件事一起猜。

可以不用 DC 吗？

可以，而且很多时候真没必要上。纯 I/O 控制、对时刻不敏感的场景，不开 DC 完全够用，还少一层调试负担。只有需要精确同步（多轴联动、高速同步采集）才值得上 DC。我自己也是先把不需要同步的那部分 I/O 跑通，确认链路没问题，再单独调 DC。

DC 和"控制器内部硬件定时器"有什么区别？

DC 是 EtherCAT 协议层的同步机制，跨厂商通用------只要从站支持 DC，就能纳入同一套系统时间。控制器内部的硬件定时器是单设备的私有能力，灵活性和可扩展性都受限。DC 的价值，在于把一整条总线上不同厂商的异构从站对齐到同一时刻。

一次完整的 DC 跑通：从扫描到伺服同步

把上面零散的步骤串起来，记一下我实际怎么从空网络跑到多轴 DC 同步的，方便照着复现：

接线、装驱动：开发机是普通 Windows 工控机，单独留一个 Intel 千兆网口给 EtherCAT，装 DarraRT 内核实时驱动，BIOS 里把 SMI 相关项按文档调好。
扫网络：图形化工具一键扫描，拓扑和从站列表都认出来了，哪些支持 DC 一目了然。我先确认参与同步的伺服轴都在 DC 那列打了勾。
先不开 DC 跑 I/O：CiA 402 走 CSP 模式，PDO 映像生成好，确认每个轴能使能、能收发位置------这一步只验证链路和 PDO，不碰同步。
开 DC、导 ENI：选中各从站启用 DC，Cycle Time 我先填 125µs 求稳，Shift Time 填 0，导出含 DC 的 ENI，顺手生成 C# 代码骨架。
量帧发送抖动：加载 DENI、配置周期、SetState(OP)，先盯主站帧发送抖动。这一档下典型 ~1.0µs、最大没超过 4.2µs，跟官网那张表对得上------地基稳，才敢往下走。
压周期：确认 125µs 稳了之后逐档往下压到 62.5µs，每压一档都回头看抖动表和 DC 同步丢失计数，没报丢失就继续。62.5µs 这一档在我的平台上稳得住。
看多轴对齐：双轴同时下发轨迹，从输出端看两轴动作的时间错位收敛到微秒级，之前那台双驱龙门的异响也跟着没了。

整个过程里我没写过一行传播延迟补偿的代码，也没量过线长------扫描一次、勾一个选项、导一次 ENI，剩下的主站自己处理。真正花我时间的是验证和压周期那几步，而不是配置本身。

复杂拓扑下会不会塌？

我这个项目轴数不多，但搭的时候还是顺手摸了下天花板，免得后面放量被卡住。这块我没机会全部实测，只能照文档和小规模验证说：DC 对常见拓扑都有支持，可靠性上也有冗余和热插拔这类机制。对要长时间连续跑的多轴系统，这几条我看重的程度其实不亚于同步精度------同步再准，断一次重启半天也白搭。具体的拓扑上限够不够用，得结合你自己的规模去评估，我只能说它没在我这个量级先掉链子。

总结

DC 是 EtherCAT 真正能扛多轴同步的核心能力。落地步骤其实不复杂：

确认参与同步的从站都支持 DC，且链路中不要插非 DC 从站。
在配置工具里启用 DC、设好 Cycle Time / Shift Time，导出含 DC 的 ENI。
代码里只管按实时周期读写零拷贝 PDO，DC 同步和传播延迟补偿交给主站自动处理。
用主站内置的 DC 同步丢失检测盯状态，别靠输出异常倒查。

但最容易被忽略的那条功课------帧发送够不够稳------才是 DC 能不能站住的地基。我自己最大的收获，反而不是哪个工具好用，而是想明白了一件事：同步精度是结果，时序稳定性才是因。把因照顾好了------在我这儿就是 DarraRT 驱动加 SMI 抑制把 Windows 抖动压到 4.2µs 这一档------DC 自然就稳了。

如果你也想动手试，SDK 文档在 ethercat.darra.xyz/。