EtherCAT与FSoE实践：STM32从站搭建及24轴伺服同步控制

做运动控制的同行，大部分都听过 EtherCAT。它几乎是目前伺服驱动和PLC之间最主流的高速总线之一，而 FSoE 则是很多项目要求达到安全等级之后不得不面对的协议。这篇文章不是教科书式的概念堆砌，而是把 EtherCAT 的通信机制、基于 STM32 的从站搭建、24轴伺服案例，以及 FSoE 安全通信的落地要点放在一起梳理。无论你是刚接触总线的新手，还是已经在现场调试的老手，都可以把这篇文章当作一份经验清单来用，遇到对应问题时直接翻章节。

我第一次认真研究 EtherCAT，是因为一台需要同步带动24个伺服轴的多工位设备。当时还在用脉冲方向控制，柜内一半空间被线槽和端子排占掉，单个轴的堵转和报警排查起来极其痛苦。后来换成 EtherCAT，线缆少了一大半，同步精度也完全不在一个级别。所以这篇内容会尽量用工程语言来说技术点，多放实操步骤和避坑记录，而不是贴满协议规范和寄存器地址表。

1. 为什么工业现场需要 EtherCAT 和 FSoE

1.1 传统控制网络的瓶颈

在没有 EtherCAT 的时期，多轴运动控制通常依赖三种方式：脉冲方向、模拟量速度跟随、或者像 PROFIBUS 这样的现场总线。脉冲方式的好处是简单、直接，但每一路脉冲都要占用一个高速输出口，长距离传输容易受干扰，而且脉冲频率决定了运动速度上限。模拟量方式虽然接线少，但抗干扰能力一般，调试起来也不够直观。PROFIBUS 这类传统现场总线解决了部分远程传输问题，但通信周期和同步精度往往做成百上千个轴的应用时比较吃力，尤其是电子凸轮、插补运动这类需要所有轴在同一时间基准上动作的场景。

普通以太网也不适合直接用于运动控制。TCP/IP 协议栈处理数据时存在存储转发机制，每一帧数据都要经过完整的解包、处理、再封装过程，延迟不确定且抖动大。即使使用 UDP，操作系统的导致实时性和确定性不足。伺服驱动器每个周期都需要固定时间收到新的目标值，一旦主站的数据晚到，驱动就可能报错甚至停机。

1.2 EtherCAT 把数据处理放到帧传输过程中

EtherCAT 针对这个问题做了一个很巧妙的改变：主站发出的帧，在物理层依次穿过每一个从站时，每个从站不是把整帧数据收完再转发，而是边收边处理，在数据流经过自己的那几十纳秒内，把需要输出的数据取走，把需要反馈的数据插入。最后一个从站再把整帧返回主站。这样整条链路上的通信时间，约等于一帧数据在物理线缆上从首站走到尾站再走回来的时间，比传统的存储转发要快得多。

打个比方，普通以太网像驿站逐站转抄信件，每一站拿到信之后再往下传。EtherCAT 则像一列从头到尾行驶的列车，每个站点只在列车经过自己时快速装上卸下货物，列车不减速、不停靠。这也是 EtherCAT 一个很短的周期内完成大量轴数据交换的基础。很多 EtherCAT 系统的过程数据周期可以做到 1 ms，高实时版本甚至可以做到 125 us 甚至更低。对于伺服驱动器来说，1 ms 的周期已经足够让位置环和速度环保持稳定。

1.3 安全需求催生 FSoE

单有高速运动总线还不够，机器还要考虑功能安全。安全性需求包括急停按钮、安全门、光栅、双手控制这些信号，传统做法是采用安全继电器模块加独立硬接线，把安全回路直接串到接触器和伺服使能回路。这种方案可靠性高，但接线多、诊断信息有限。安全门开关哪里断开了、急停按钮是哪个触发，只能靠人工去查。

FSoE 全称是 Safety-over-EtherCAT，解决的就是“让安全数据也走 EtherCAT 这条线”的问题。它在 EtherCAT 周期数据中开辟出一段安全通信通道，由安全控制器和安全从站之间通过协议层校验来保证数据完整性。FSoE 可以做到 SIL3 或 PLe 等级，同时保留了普通 EtherCAT 的高速和诊断能力。也就是说，一根网络里同时跑运动控制和安全监控，不但省了安全继电器的布线，还能在 HMI 上直接看到安全状态。这也是大型自动化设备越来越倾向于 FSoE 的原因。

2. EtherCAT 通信机制拆解：主站、从站、帧、时钟

2.1 主站与从站角色

EtherCAT 网络里，主站是唯一可以主动发起通信的节点。从站一般分为两类：一类是带 ESC（EtherCAT Slave Controller）芯片的硬件从站，比如伺服驱动器、I/O 模块；另一类是由软件实现从站功能的软从站，但实时性要求高的场合基本不用软方案。主站负责发送下行帧、接收上行帧，并且维护整个网络的通信状态。从站不会主动发数据，它只能等主站的帧经过时，把自己的输入数据填进帧中的对应位置。

EtherCAT 从站的通信状态机需要理解，共有四种状态：INIT、PRE-OP、SAFE-OP、OP。主站先把从站从 INIT 切到 PRE-OP，此时可通过邮箱通信配置从站参数，例如 EEPROM、对象字典、PDO 映射。接着切到 SAFE-OP，从站进入安全输出状态，开始接收周期输入数据，但输出默认保持安全值。最后切到 OP，从站正常输出过程数据。很多现场调试问题，本质上就是状态机卡在某个转换步骤，比如从站没能正确收到邮箱数据，或者主站要求的配置与从站不符。

2.2 一帧数据在站间“边收边发”

理解 EtherCAT 的帧转发机制，是理解后续所有调测问题的基础。主站发送的标准以太网帧，内部会携带多个子报文，每个子报文对应一个或多个从站设备。当帧到达第一个从站时，从站内部的 ESC 会解析帧头，判断子报文中的寻址信息是否与自己匹配。如果匹配，就按需要把输出数据写入自己的输出内存，并把自己的输入数据复制到子报文的相应字段；如果不匹配，就直接跳过。整帧数据随后转发到下一站，直至最后一个从站把帧返回给主站。

这种工作方式对从站硬件提出了要求：每一个以太网物理层和 ESC 之间的数据吞吐延时必须非常小。这也是为什么要使用专用 ESC 芯片，而不是直接用普通以太网 MAC。ESC 芯片内部的硬件逻辑可以在几十纳秒内完成子报文的处理，不依赖 CPU 和协议栈，因此延时可以忽略不计。

2.3 寻址方式：位置寻址与站寻址

从站被识别的过程，主站通常使用位置寻址，也就是按照物理连接顺序从 1 开始编号。第一个从站是位置 1，第二个是位置 2，以此类推。配置完成之后，主站会为每个从站分配一个独立的配置地址，后续运行阶段使用站地址通信。这种方式的好处是即使在从站完全没配置的情况下，主站也能通过位置寻址扫描到所有节点。

实际调试时最容易犯的错：修改了某段网线的连接顺序，或者从站节点被跳过，却忘了重新扫描和分配地址。结果报了某个站掉线，其实只是物理拓扑变了，位置编号全乱了。所以现场改线后一定要重新扫描拓扑，而不是只看 PLC 程序里的轴配置。

2.4 分布时钟与同步抖动

对于多轴同步控制来说，光能通信还不够，所有轴必须在同一时刻采样命令和反馈，否则插补出来的轨迹就会失真。EtherCAT 的分布时钟（DC）解决了这个问题。网络中的第一个具备 DC 能力的从站通常被当作参考时钟，主站通过测量每一段链路的传播延时，给每个从站计算出时钟偏移量，然后周期性地发出 SYNC 同步信号。从站本地电机驱动器在自己的 SYNC 中断中执行采样和输出，保证各轴动作在同一时刻发生。

DC 的同步精度是整个系统性能的关键。普通任务的实时性但轴同步要求高时，最大的问题不是带宽，而是抖动。如果线缆质量差、EMC 干扰严重，或者从站 ESC 的时钟源精度不够，SYNC 脉冲的间隔就会出现抖动，导致各轴实际启动时刻不一致。现场判断方式很简单：当多轴联动时，观察轨迹是否有周期性的梨形误差；在伺服驱动器侧一般都能看到“同步丢失”或者“DC 超时”的报警。

2.5 CSP 模式：周期性同步位置控制

在开发 EhtherCAT 伺服应用时，你可能经常听到 CSP、CSV、CST，这是 CiA 402 驱动配置文件中定义的三种周期性同步模式。CSP 是 Cyclic Synchronous Position，周期性同步位置控制。简单说，主站每个通信周期把目标位置下发到伺服驱动器，驱动器在这个周期内执行位置环计算，并且结合速度前馈和力矩前馈进行插补。CSP 适合电子凸轮、齿轮联动、多轴插补这类应用，也是做运动控制最常用的模式之一。

使用 CSP 模式时要注意，主站下发的目标位置必须是平滑的变化量，不能每周期跳变。比如电子凸轮表生成的理想位置值，需要经过滤波或规划器处理后再下发。否则驱动器容易跟随不上，出现位置误差大报警。另外，CSP 模式下一定要设置好驱动器侧的定位裕度和位置误差上限，否则一旦位置同步失败，很难判断是通信问题还是规划参数问题。

3. 实操：基于 STM32 构建 EtherCAT 从站

3.1 方案选型：ESC 芯片加 MCU 还是集成式

很多工程师对 EtherCAT 从站的第一印象是“高不可攀”，但其实基于 STM32 做从站已经有非常成熟的路径。常见做法是采用 ESC 芯片加应用 MCU 的双芯片结构，由 ESC 芯片处理 EtherCAT 实时通信，STM32 做应用逻辑和协议栈。这样分工明确，实时性由硬件保证，应用开发也灵活。最常见的 ESC 芯片包括 LAN9252、AX58100、ET1100 等。LAN9252 和 AX58100 都支持通过 SPI 和外部 MCU 交换数据，非常适合与 STM32 配合使用。

也可以采用带 EtherCAT 从站 IP 核的 SoC 方案，或者直接用集成 ESC 的专用芯片，但这类方案通常灵活性不如 MCU 方案，价格和供货也不一定占优。对于绝大多数自研 I/O 模块、小型伺服驱动、阀岛、传感器等产品，我建议优先考虑 LAN9252 加 STM32，因为参考资料最多，SSC 代码移植也最省事。如果只做六轴以下的小型控制器，还可以考虑用主站侧软件代替，但从站方面仍然需要 ESC 硬件。

3.2 用 SSC 生成从站协议栈代码

硬件确定后，下一步就是生成从站协议栈。Beckhoff 的 SSC（Slave Stack Code）工具是主流选择。你可以在软件里选择 ESC 类型，配置支持的功能，生成一个包含 EtherCAT 从站基础通信代码的工程，然后再把它移植到 STM32 项目中。SSC 生成的代码包含协议栈主循环、邮箱状态机、对象字典、PDO 映射管理，以及 ESC 寄存器操作接口。你要做的不是从零写协议，而是把底层接口换成对应的芯片 SPI 驱动。

配置 SSC 时，要重点关注三处：一是选择 ESC 型号，SSC 会对应生成不同的 EEPROM 配置字；二是配置邮箱通信，通常勾选 CoE（CANopen over EtherCAT），必要时勾选 FoE；三是配置同步模式，如果使用 DC，需要确保 STM32 能响应 SYNC 中断。很多新人把 SSC 生成代码之后直接编译，却看到一大堆原生文件，不知道怎么和 STM32 工程融合。建议的做法是先建一个空的 STM32 裸机工程，把 SSC 生成的 src、include 文件夹整体拷贝过去，然后只修改与硬件相关的驱动文件，比如 SPI、定时器、EEPROM、LED 状态指示。

3.3 最小流程：SPI 读写到周期 PDO 交换

把协议栈跑起来的最小验证流程一般是这样的。第一步，初始化 STM32 的 SPI、中断和定时器。第二步，初始化 ESC 芯片，读取芯片型号和 EEPROM 内容。第三步，启动协议栈任务，周期调用主函数。之后用一台可以当主站调试工具的设备，比如 TwinCAT 或者专用的 EtherCAT 主站网卡，扫描从站。如果能识别到设备描述文件和站地址，说明 ESC 物理链路基本没问题。

接下来，主站会通过邮箱配置从站，把从站从 INIT 切到 PRE-OP，再切到 SAFE-OP。此时从站的输出数据会保持为安全值，主站可以开始周期把输入输出数据映射到过程数据区。最后切到 OP，从站输出使能，松开互锁。很多人在这一步卡住，因为 PDO 映射表中没有把应用数据区和 ESC 的过程数据地址关联起来。SSC 生成的代码里有专门的变量，比如Inputs和Outputs结构体，你需要把自己要发送的数据填入这两个结构体，协议栈会在每个通信周期自动和 ESC 寄存器交换。

下面是一个简化的伪代码片段，展示移植时需要关注的周期任务：

void ETHERCAT_Application(void) { ESC_ProcessDataExchange(); if (Sync0InterruptFlag) { /* 从主站收到的输出数据 */ servo_ctrlword = RxPdo.ControlWord; servo_setpoint = RxPdo.TargetPosition; /* 更新反馈数据，下一周期返回给主站 */ TxPdo.StatusWord = servo_status; TxPdo.ActualPos = encoder_position; } }

这个循环里最重要的一点是：对伺服应用而言，过程数据交换和 SYNC 中断必须严格对应。如果你没有在 SYNC 中断里同步采样，而是用主循环随机方式刷新数据，即使通信正常，控制性能也会很差。

3.4 编译告警 #767-d 的排查思路

如果你在做 STM32 从站编译时看到类似..\ethercat\objdef.c(890): warning: #767-d: conversion from pointer to small的告警，不用太紧张。这个告警通常不是逻辑错误，而是编译器发现代码中把指针类型的值转换到了更小的整型变量。常见原因有三个：一是 SSC 生成代码基于旧版编译器，和当前 IAR 版本的字长处理不一致；二是协议栈里某些变量定义为指针，但底层接口函数接收的是 16 位或 8 位整型；三是在做强制转换时，没有通过中间类型uintptr_t过渡，导致编译器告警。

排查顺序通常是：先找到告警对应的源文件行号，看它是否来自 SSC 原装代码；如果是原装代码，优先检查编译器的数据类型大小设置，确认 int 和指针是否都是 32 位；如果不是原装代码，检查自己的 SPI 缓冲区和协议栈缓冲区之间是否有指针赋给短整形变量。我的经验是，只要没有强转后丢失地址导致访问越界，这种告警多数不影响功能，但发布前建议还是处理一下，可以用uintptr_t中转，也可以把目标变量改成同等位宽，而不是直接屏蔽所有告警。

4. 案例复盘：汇川 H5U 带 24 台 660 伺服轴

4.1 系统拓扑与连接方式

回到我调试过的实际案例：主站是汇川 H5U 系列 PLC，从站是 24 台 660 系列伺服驱动器。H5U 内置 EtherCAT 主站，理论上可以带几十个轴，但实际能否稳定运行，很大程度取决于拓扑、线缆和参数配置。连接方式采用 EtherCAT 标准菊花链，主站网口接到第一台伺服驱动器的 EtherCAT IN 口，再从这个驱动器的 OUT 口接到第二台，如此串联，直到第 24 台。

很多新手以为 EtherCAT 也需要像 CAN 总线那样加终端电阻，其实不用。EtherCAT 物理层基于标准 100BASE-TX，链路是逐点转发的，不需要终端匹配。但线缆要求并不低，建议使用带屏蔽的工业以太网线，最好是遮蔽双绞线，并且尽量和动力线分开布槽。24 台设备串联的链路总长度要控制在线缆允许范围内，一般每段不超过 100 米，整套设备通常远小于这个限制，但实际现场干扰才是主要变数。

4.2 主站配置与 PDO 映射

汇川 H5U 的 EtherCAT 配置在编程软件里完成。第一步是添加 EtherCAT 主站，然后通过扫描拓扑识别从站。扫描时主站会读取每台 660 驱动器的站信息，自动生成设备树。这里要注意，24 台驱动器型号相同，软件可能会默认分配依次递增的站地址，但你最好手动核对一下顺序，特别是中途有设备跳线或跨接的时候。

第二步是配置每个轴的 PDO 映射。660 伺服驱动器通常支持 CiA 402 标准对象，核心对象包括：控制字 6040h、状态字 6041h、运行模式 6060h/6061h、目标位置 607Ah、实际位置 6064h、电子齿轮比 6091h 等。在 CSP 模式下，我们需要把控制字、模式字、目标位置等对象放入主站发送给从站的 RxPDO，把状态字、实际位置、实际速度等放入从站反馈给主站的 TxPDO。映射错误的最常见表现是轴能上电，但使能后没有任何动作，或者状态字永远是某个固定值，因为控制命令根本没进到驱动器。

第三步是配置 DC 同步。24 轴系统尤其需要把分布时钟功能打开，一般选择第一个支持 DC 的从站作为参考时钟，其余从站自动进行偏移补偿。参数配置完成后，主站会按照设定的周期，比如 1 ms，周期性地发送同步帧。H5U 的运动指令通过 PLC 程序调用，但在底层已经把目标位置值填到对应轴的 PDO 之中。

4.3 调试中遇到的实际问题

这个项目开始调试时，第一个问题是第 15 台驱动器偶发掉站。排查了一个上午，最终发现原因是两段网线经过了同一条与变频器主线路靠近的线槽，电磁干扰导致链路误码率升高。把 EtherCAT 线缆重新布线，换成更低延时的屏蔽线，并在联接端子处重新压接后，掉站现象消失。这个经验反复证明：只要链路物理层不稳，改协议参数效果有限。

第二个问题是多轴同步有轻微误差。启用 DC 后，前几个轴动作基本一致，但最后几台轴在连续运动时会有位置累积偏差。这通常是因为参考时钟选择不理想，或者从站 DC 补偿计算没有生效。解决方法是把参考时钟固定为第一个伺服轴，同时检查各从站驱动器的 DC 锁存功能是否开启。有些驱动器需要在功能码里使能“SYNC 同步模式”，否则它虽然能从 EtherCAT 收到 PDO，但并没有按照 SYNC 中断来执行位置控制，只是按自身周期运行。

第三个问题是新手最容易踩的坑：在没验证两轴的情况下直接配置 24 轴。结果主站启动后有一台驱动器报警，导致整个网络回退到 SAFE-OP。后来调整调试流程：先在 H5U 工程里只使能两个轴，验证点动、回零、位置控制、状态字反馈，再逐步启用其余轴。这样排查范围小很多，出现问题时能快速定位是主站配置、驱动器参数，还是网络物理链路的问题。

5. FSoE 安全通信：原理与落地

5.1 FSoE 在 EtherCAT 协议栈中的位置

FSoE 不是一个全新的物理层标准，它运行在普通 EtherCAT 之上，相当于在过程数据通道里划出一块专门用于安全通信的区域。从OSI层次来看，EtherCAT 负责传输，FSoE 负责安全协议。标准 EtherCAT 主站并不需要理解 FSoE 安全数据内容，它只当作普通 PDO 的一部分进行转发。真正解析和处理安全数据的是安全 PLC 或者安全从站内部的 FSoE 协议栈。

功能安全有一个概念叫“黑通道”，意思是通信链路本身被视为不可靠的，所有错误检测和纠正都要在安全协议层完成。FSoE 的做法是给每个安全数据帧加上连接 ID、帧计数、CRC 校验和看门狗时间戳。接收方如果发现帧丢失、帧顺序错、数据被篡改、超时，都会把安全输出设置到安全状态。正因为有这一层独立的校验机制，FSoE 才能和普通 EtherCAT 共享链路而不互相干扰。这也是为什么在欧洲标准 IEC 61784-3 中，FSoE 可以被认证到 SIL3。

5.2 FSoE 连接建立与数据交换

在一个实际的 FSoE 系统里，安全主站每个周期和每一个安全从站分别交换一个安全帧。安全帧可以携带最多几百字节的安全数据，但实际项目通常只传输急停、安全门、光栅、安全输出等布尔状态。其中 Connection ID 是每个 FSoE 连接的唯一标识，主站和从站必须配置成相同值才能建立连接。看门狗时间决定了多长时间没收到安全帧就算失效。

建立连接的过程类似状态机切换：先经过离线、初始化、建立连接等状态，最后进入安全数据交换状态。收到错误安全帧时，连接会进入错误状态，并把安全输出切断。工程上几乎没人会手写 FSoE 底层协议栈，因为需要经过功能安全认证，成本极高。你通常会使用已经认证过的 FSoE 协议栈库，只需要配置连接参数，并在应用层调用收发 API。下面是一个通用化的调度示意：

void SafetyTask(void) { FSoE_Process(); if (fs_conn.Status == FSOE_SAFE_OPERATIONAL) { SafetyData.Tx.EStopState = esInput ? FSOE_STATE_FALSE : FSOE_STATE_TRUE; FSoE_Send(&fs_conn, &SafetyData.Tx); FSoE_Receive(&fs_conn, &SafetyData.Rx); SafeOutput = SafetyData.Rx.SafeEnable; } else { SafeOutput = 0; } }

这个代码里最需要注意的地方：安全输出不能只看应用层的布尔变量，必须在 FSoE 连接进入安全运行状态之后才允许输出。任何超时、CRC 错误、ID 不匹配，协议栈都会自动把状态切到非安全状态，此时你的应用代码需要无条件切断输出。

5.3 安全从站开发要点

如果要做带 FSoE 的从站产品，建议从设备侧和系统侧同时考虑。设备侧，安全数据采集和输出应该采用双通道或者多样化的结构。所谓双通道，就是急停信号经过两路独立的输入电路进入 MCU，MCU 内部用两个独立逻辑运算后比较结果；或者使用同构冗余，两片 MCU 交叉校验。多样化的意思是，两个通道不能是简单的复制，最好由不同设计或不同指令集完成，这样可以避免“共因故障”。如果没有做过这类设计，建议先找有功能安全经验的同事或者外部顾问评估架构，不要直接套普通总线设备的架构。

系统侧，FSoE 通信的参数必须在主站和从站之间严格一致，包括连接 ID、看门狗超时、安全数据长度。调试 FSoE 时，建议先用普通模式确认 EtherCAT 链路本身稳定，再让主站建立安全连接。如果安全连接一直建立不起来，多半是安全主站配置的安全数据长度与从站不一致，或者从站没有处于安全运行状态。另一个常见问题是看门狗时间设置太短，EtherCAT 周期在启动瞬间出现了几个周期超时，导致 FSoE 连接反复断开。可以先放宽看门狗，等链路稳定后再逐步收紧到目标值。

6. 常见问题速查与调测技巧

下面把 EtherCAT 和 FSoE 调试中比较常见的问题整理成一个速查表。这张表里的排查顺序，我建议在遇到问题时按“物理层 -> 数据链路层 -> 应用层”逐一检查，不要一上来就怀疑协议栈。

除了这些固定问题，还有两个调测技巧非常实用。第一个技巧是抓包。调试 EtherCAT 时如果条件允许，最好用支持 EtherCAT 分析的软件或者在主站侧抓帧，看子报文有没有从站返回错误码。第二个技巧是分段排除。24 轴项目里如果只有某一段出现报警，把这段前后的网线互换，看报警是否跟随互换，从而快速定位是设备问题还是线缆问题。

最后说一个我在现场最深切的体会：不论 EtherCAT 还是 FSoE，真正难的不是协议本身，而是基础链路的质量。链路稳，所有上层调试都很快；链路不稳，所有上层参数都是隔靴搔痒。对新手来说，最稳妥的路是先买一套带 ESC 的从站开发板和一张普通 EtherCAT 主站网卡，把两轴通信跑通，再加入安全继电器模拟一个急停信号，逐步扩展到完整系统。这样积累的经验，比直接拿 24 轴项目去试要可靠得多。如果你正准备做类似的项目，先把线和拓扑验证好，再花时间调参数，过程会顺利很多。