2. EtherCAT协议栈：数据帧结构、寻址方式与通信模式

好，咱们接着聊。上一章我们把EtherCAT的物理层和整体架构理了一遍，这一章要深入协议栈的核心了。说白了，就是搞清楚数据在总线上到底是怎么跑的，怎么找到目标设备，以及设备之间怎么对话。

我个人习惯把EtherCAT协议栈分成三个层面来理解：数据帧怎么封装、设备怎么被找到、应用层用什么语言沟通。这三个层面搞透了，你写配置、调参数、排故障的时候心里就有底了。

2.1 EtherCAT数据帧结构

先看数据帧。EtherCAT的数据帧是直接封装在标准以太网帧里面的，这一点很巧妙。它没有重新定义物理层，而是把数据塞进了以太网的数据载荷区。

一个标准的EtherCAT数据帧长这样：

+----------------+----------------+----------------+----------------+
|  Ethernet Header  |  EtherCAT Header |  EtherCAT Datagrams  |  FCS  |
|  (14 bytes)       |  (2 bytes)       |  (多个子报文)         |  (4 bytes) |
+----------------+----------------+----------------+----------------+

以太网头部的MAC地址，目的地址通常是广播地址或者特定从站地址。EtherCAT头部的2个字节里，有个关键字段叫长度/类型，它告诉交换机或者从站：这是个EtherCAT帧，不是普通IP包。

真正干活的是后面的EtherCAT数据报。一个帧里可以塞多个数据报，每个数据报都有自己的头、数据和工作计数器（WKC）。

数据报的结构是这样的：

+----------------+----------------+----------------+----------------+
|  数据报头(10字节) |  数据区(最多1486字节) |  工作计数器WKC(2字节) |
+----------------+----------------+----------------+----------------+

数据报头里包含了寻址信息、命令类型、长度等。WKC是个好东西，它记录了有多少个从站成功处理了这个数据报。我调试的时候经常盯着WKC看——如果WKC的值不对，说明有从站没响应或者处理失败了。

2.2 寻址方式

数据报里写了目标地址，从站怎么知道自己该不该处理这个报文呢？EtherCAT提供了好几种寻址方式，我挑最常用的三种讲。

2.2.1 设备寻址

每个从站在上电后会被分配一个站地址（也叫节点地址）。主站通过这个地址直接访问某个从站。这种方式简单粗暴，适合参数配置、固件下载这类操作。

站地址有两种：

• 配置站地址：由主站在启动阶段分配，掉电后需要重新分配。
• 固定站地址：从站硬件引脚或EEPROM里写死的地址，一般不常用。

我在项目里遇到过一个问题：两个从站的配置站地址冲突了，结果主站死活连不上其中一个。排查了半天才发现是地址分配逻辑有bug。嗯，这里要注意，地址分配一定要做冲突检测。

2.2.2 逻辑寻址

这是EtherCAT最强大的地方。主站把整个总线的过程数据映射到一个连续的逻辑地址空间里，每个从站只负责读写自己对应的那一段。数据报里不写具体从站地址，只写逻辑地址和长度。

举个例子：

逻辑地址 0x0000 - 0x003F: 从站1的输入数据 (64字节)
逻辑地址 0x0040 - 0x007F: 从站2的输入数据 (64字节)
逻辑地址 0x0080 - 0x00BF: 从站3的输入数据 (64字节)
...

每个从站内部有个FMMU（现场总线内存管理单元），它负责把逻辑地址映射到从站自己的物理内存地址。主站发一个数据报，所有从站同时处理，效率极高。

2.2.3 广播寻址

主站发一个数据报，所有从站都必须处理。这种模式常用于同步信号、启动命令或者全局复位。广播寻址的WKC会累加所有从站的响应次数，主站通过WKC可以知道有多少从站在线。

2.3 通信模式：CoE、SoE、FoE、EoE

数据帧和寻址是底层机制，应用层协议才是我们真正打交道的东西。EtherCAT支持多种应用层协议，我一个个说。

2.3.1 CoE（CANopen over EtherCAT）

这是最常用的模式，没有之一。CoE把CANopen的对象字典、PDO、SDO这些概念搬到了EtherCAT上。如果你用过CANopen，上手CoE会非常快。

CoE的核心是对象字典，每个对象有一个16位的索引和8位的子索引。主站通过SDO（服务数据对象）读写对象字典，通过PDO（过程数据对象）实时交换数据。

举个例子，读取一个驱动器的状态字：

索引: 0x6041 (状态字)
子索引: 0x00
访问方式: SDO 读

CoE的SDO通信是确认模式的，主站发请求，从站回响应。PDO则是无确认的，主站周期性发送，从站自动更新。

2.3.2 SoE（Servo Drive over EtherCAT）

SoE是专门为伺服驱动器设计的协议，它继承了SERCOS接口的很多概念。如果你用的是高端伺服驱动器，比如某些日系品牌，可能会遇到SoE。

SoE使用IDN（标识号）来寻址参数，类似于CoE的对象字典。但SoE的通信机制更复杂，支持周期同步位置、速度、转矩等多种模式。

说实话，我在实际项目中用SoE不多，大部分伺服驱动器都支持CoE了。但如果你维护的是老系统或者特定品牌的驱动器，SoE还是得会。

2.3.3 FoE（File over EtherCAT）

FoE用于文件传输，比如固件升级、配置文件下载。它简单直接，主站把文件拆成数据报，从站接收并写入本地存储。

FoE的典型应用场景：

• 从站固件升级（比如更新驱动器的Firmware）
• 下载配置文件（比如XML设备描述文件）
• 上传诊断日志

FoE的传输是可靠的，有确认和重传机制。但速度不算快，适合小文件传输。大文件的话，我建议还是用其他方式。

2.3.4 EoE（Ethernet over EtherCAT）

EoE允许在EtherCAT总线上传输标准以太网帧。说白了，就是把EtherCAT当成一个虚拟交换机，让从站之间或者从站与外部网络之间进行IP通信。

EoE的典型用途：

• 从站之间通过TCP/UDP通信
• 从站访问外部网络（比如上传数据到MES系统）
• 调试时用Wireshark抓包分析

但要注意，EoE会占用总线带宽，而且实时性不如PDO。我一般只在调试阶段或者非实时通信场景下用EoE。

好了，这一章的内容就这些。数据帧结构、寻址方式、四种通信模式，都是EtherCAT协议栈的基础。下一章我们会讲如何根据这些知识来计算总线负载，那才是真正考验工程能力的地方。