4. 邮箱数据协议：邮箱报头结构、数据类型（CoE, FoE, SoE, AoE）
好，咱们接着聊。上一节我们把邮箱通信的底层机制——握手和通道管理讲清楚了。这一节，我们聚焦在邮箱里真正传输的“货”——也就是邮箱数据协议。
你想想看，邮箱就像一个快递通道。通道建好了，但里面传的是什么？是配置文件？是固件升级包？还是伺服驱动的参数？不同的“货”，需要不同的打包规则。这就是我们今天要讲的邮箱报头和四种数据类型。
4.1 邮箱报头结构：快递单怎么填？
每一封邮箱报文，前面都带一个固定的报头。这个报头告诉从站：这封邮件是什么类型、多长、有没有分片。
我直接给你看结构，这是EtherCAT规范里定义的：
邮箱报头（Mailbox Header）—— 共6字节
+--------+--------+--------+--------+--------+--------+
| 长度 (2字节) | 通道 (2字节) | 优先级 (1字节) | 类型 (1字节) |
+--------+--------+--------+--------+--------+--------+咱们拆开来看：
- 长度（2字节）：表示后面跟着的数据长度，单位是字节。注意，这个长度不包括报头本身。我在项目中遇到过有人把总长度算进去，结果从站直接报错——嗯，这个坑我踩过。
- 通道（2字节）：实际上低4位才有效，用来标识邮箱通道号。一般我们只用0，除非你搞多通道。
- 优先级（1字节）：0是正常，1是高优先级。说实话，我很少见到有人用高优先级，因为邮箱本身就不是实时通道。
- 类型（1字节）：这个最关键。它决定了后面的数据怎么解释。0x01是FoE，0x02是SoE，0x03是CoE，0x04是AoE。后面我们一个一个讲。
重点记住：类型字节是解析邮箱数据的“钥匙”。主站发什么类型，从站就必须按同类型解析。否则就是鸡同鸭讲。
4.2 CoE（CANopen over EtherCAT）：最常用的协议
CoE，说白了就是把CANopen那一套对象字典搬到了EtherCAT上。这是工业自动化领域用得最多的邮箱协议，没有之一。
为什么？因为CANopen的SDO（服务数据对象）机制太成熟了。你想想看，伺服驱动器、IO模块、编码器，几乎每个设备都有对象字典。CoE就是让这些设备无缝迁移到EtherCAT上。
CoE的邮箱数据格式是这样的：
CoE邮箱数据格式：
+--------+--------+--------+--------+--------+--------+--------+
| 头部 (2字节) | 索引 (2字节) | 子索引 (1字节) | 数据 (N字节) |
+--------+--------+--------+--------+--------+--------+--------+头部里最关键的是服务类型：
- 0x40：读请求（上传）
- 0x80：读响应
- 0x20：写请求（下载）
- 0x60：写响应
- 0xA0：信息请求
我个人习惯把CoE通信分成两种场景：
- 启动时参数配置：主站通过CoE把伺服驱动的增益、限位、通讯参数写进去。这时候用的是写请求（0x20）。
- 运行时诊断读取：比如读当前温度、读错误代码。这时候用读请求（0x40）。
我的经验：CoE的SDO通信是确认模式，主站发一个请求，从站必须回一个响应。如果你发现通信卡住了，八成是从站没响应，或者响应超时。我曾经调试一个驱动器，死活读不到对象字典，最后发现是子索引写错了——0x00写成了0x01，差一个字节，结果完全不一样。
4.3 FoE（File over EtherCAT）：传文件用的
FoE，全称是File over EtherCAT。听名字就知道，它是用来传文件的。最常见的场景就是固件升级。
你想想看，一个产线上有几十个伺服驱动器，每个都要升级固件。如果用串口一个一个刷，工程师得累死。FoE就是干这个的——主站把固件文件通过邮箱发给从站，从站自己写进Flash。
FoE的报文结构相对简单：
FoE邮箱数据格式：
+--------+--------+--------+--------+--------+--------+
| 头部 (1字节) | 错误码 (4字节) | 文件名 (变长) | 数据 |
+--------+--------+--------+--------+--------+--------+头部里的命令类型：
- 0x01：读请求（从站上传文件到主站）
- 0x02：写请求（主站下载文件到从站）
- 0x03：数据包
- 0x04：确认包
- 0x05：错误包
注意：FoE传输的文件名必须是ASCII字符串，而且长度有限。我曾经见过有人用中文文件名，结果从站根本不认——嗯，这个坑我也踩过。老老实实用英文+数字吧。
4.4 SoE（Servo over EtherCAT）：伺服专用协议
SoE，全称是Servo over EtherCAT。它是从SERCOS III继承过来的，专门用于伺服驱动器的参数访问。
SoE和CoE有什么区别？我打个比方：CoE是通用协议，什么设备都能用；SoE是专用协议，只给伺服驱动器用。SoE里定义了IDN（识别号）的概念，每个参数都有一个唯一的IDN编号。
SoE的邮箱数据格式：
SoE邮箱数据格式：
+--------+--------+--------+--------+--------+--------+
| 头部 (2字节) | IDN (2字节) | 数据 (N字节) |
+--------+--------+--------+--------+--------+--------+头部里的服务类型：
- 0x01：读请求
- 0x02：读响应
- 0x03：写请求
- 0x04：写响应
说实话，现在很多伺服驱动器同时支持CoE和SoE。我个人更倾向于用CoE，因为通用性更好。但如果你用的是老派的SERCOS用户，他们可能更习惯SoE。
4.5 AoE（ADS over EtherCAT）：自动化设备专用
AoE，全称是ADS over EtherCAT。它是Beckhoff的TwinCAT系统里用的协议，用于访问自动化设备内部的ADS变量。
AoE的报文结构：
AoE邮箱数据格式：
+--------+--------+--------+--------+--------+--------+--------+
| 头部 (2字节) | 目标NetId (6字节) | 源NetId (6字节) | 命令 (2字节) | 数据 |
+--------+--------+--------+--------+--------+--------+--------+AoE最特别的地方是它带了NetId（网络标识符）。这意味着你可以跨设备通信——比如主站通过AoE去读另一个从站的数据。这在TwinCAT的分布式控制里非常常见。
一句话总结四种协议：
- CoE：通用参数访问，最常用
- FoE：文件传输，固件升级专用
- SoE：伺服专用，老派SERCOS用户
- AoE：TwinCAT专用，跨设备通信
4.6 四种协议的对比
我整理了一个表格，方便你对比：
| 协议 | 全称 | 主要用途 | 典型场景 | 报文头部长度 |
|---|---|---|---|---|
| CoE | CANopen over EtherCAT | 对象字典访问 | 参数配置、诊断 | 2字节 |
| FoE | File over EtherCAT | 文件传输 | 固件升级 | 1字节+文件名 |
| SoE | Servo over EtherCAT | 伺服参数访问 | 驱动器调试 | 2字节 |
| AoE | ADS over EtherCAT | 跨设备ADS通信 | TwinCAT分布式控制 | 2字节+NetId |
4.7 知识体系图
下面我用一张SVG图来展示本章的知识结构，帮你理清思路：
这张图把邮箱报头的四个字段和四种协议的关系画清楚了。你从类型字节出发，就能找到对应的协议，然后就知道怎么解析后面的数据了。
避坑指南：我曾经在一个项目里，主站发了CoE报文，但从站配置成了SoE模式。结果从站一直不回响应，我查了整整一天才找到原因——类型字节对不上。所以，调试时第一件事就是确认主站和从站的协议类型是否一致。
好了，这一节的内容就到这里。邮箱报头是基础，四种协议是工具。你只要记住：类型字节是“钥匙”，协议是“锁”，对上号了，数据就能流通。
公众号:蓝海资料掘金营，微信deep3321