4. 过程数据对象与邮箱通信
EtherCAT 的通信机制可以分成两条完全不同的“车道”：一条是每个周期都在跑的过程数据对象（PDO），另一条是按需触发的邮箱通信（Mailbox）。理解这两条车道的分工，是判断一个 EtherCAT 网络实时性能上限和诊断能力边界的基础。很多现场问题——比如“为什么改了参数不生效”“为什么诊断信息读不出来”“为什么固件升级会打断生产”——本质上都是把这两条车道的用途搞混了。
PDO：周期性过程数据，实时性的主通道
PDO 承载的是从站与主站之间每个通信周期都要交换的实时数据，例如伺服驱动器的目标位置、实际位置、状态字、控制字，或 IO 模块的输入输出位。它的关键特征是：由主站周期性下发，从站按固定映射在过程数据帧中读写，不需要握手确认。正因为没有逐条确认，PDO 才能做到微秒级抖动和极低的协议开销。
PDO 的映射关系由对象字典中的 0x1C12（RxPDO 分配）、0x1C13（TxPDO 分配）以及各 PDO 映射对象（如 0x1600、0x1A00）定义。主站启动时通过 SDO 把这些映射写下去，之后每个周期只按映射搬运数据。也就是说：PDO 的“配置”走邮箱，PDO 的“运行”走过程数据，这是两条车道协作的典型方式。
PDO 的实时性由三个量共同决定：通信周期（如 1 ms、500 μs、250 μs）、PDO 映射长度（字节数越多，帧越长）、以及分布式时钟（DC）同步精度。以一台 8 轴伺服为例，若每轴映射 12 字节输入 + 12 字节输出，总过程数据约 192 字节，在 100 Mbit/s 全双工下单帧传输时间约 15 μs，加上从站转发延迟，1 ms 周期内余量充足；但若把周期压到 125 μs，就必须重新核算帧长和从站处理时间，否则会出现工作计数器（WKC）不匹配。
邮箱通信：SDO、CoE、FoE、EoE、AoE 的分工
邮箱通信是非周期性、面向连接、带确认的通道，用于参数配置、诊断读取、固件传输和网络封装。它不参与每个周期的实时数据交换，因此不会直接占用过程数据的带宽，但会占用从站邮箱缓冲区和主站处理时间。EtherCAT 邮箱协议栈在应用层上支持多种协议，常见的有：
- SDO（Service Data Object）：基于 CoE 的对象字典读写服务，用于上传/下载参数、读取诊断条目。SDO 有分段传输和块传输两种模式，适合传输几十字节到几 KB 的数据。
- CoE（CANopen over EtherCAT）：把 CANopen 的对象字典、PDO 映射、SDO 服务、紧急事件（Emergency）搬到 EtherCAT 上，是绝大多数伺服和 IO 从站使用的应用层协议。
- FoE（File over EtherCAT）：文件传输协议，典型用途是固件升级、配置文件下载。FoE 传输大文件时耗时长，会占用邮箱通道，通常需要在停机或维护窗口执行。
- EoE（Ethernet over EtherCAT）：把标准以太网帧封装进 EtherCAT 邮箱，使从站可以拥有 IP 地址、跑 HTTP、Telnet 或 Modbus TCP。EoE 适合诊断和调试，但带宽和实时性远低于 PDO。
- AoE（ADS over EtherCAT）：把 Beckhoff ADS 命令封装进邮箱，用于访问从站内部变量、调用服务，常见于 TwinCAT 体系下的深度诊断和参数访问。
这五种协议并不是并列关系：CoE 是应用层协议族，SDO 是 CoE 内的一种服务；FoE、EoE、AoE 则是与 CoE 并列的邮箱协议类型。一个从站可以同时支持 CoE 和 FoE，也可以只支持 CoE。判断从站支持哪些协议，看 ESI 文件中的 Mailbox 节点和 Protocols 列表即可。
不同通信类型对实时性与诊断能力的支撑
把上面的结构落到工程判断上，可以得到几条清晰的结论。
实时性方面，PDO 是唯一直接决定控制周期和抖动指标的通道。优化实时性时，应优先压缩 PDO 映射长度、减少每周期交换的从站数量、合理设置 DC 同步模式，而不是去调邮箱参数。邮箱通信虽然不占过程数据帧，但如果邮箱任务与过程数据任务共享同一个主站 CPU 核，或从站邮箱处理占用 ESC 资源，仍可能间接影响周期稳定性。因此在高实时场景下，通常把 SDO 配置放在启动阶段完成，运行阶段只保留必要的诊断读取。
诊断能力方面，邮箱通道承担了绝大部分“可读信息”的获取。CoE 的 SDO 可以读取 0x10F3 诊断历史、0x603F 错误码、0x6061 运行模式等；Emergency 报文会在故障发生时主动上报；FoE 可以回读固件版本和配置文件；EoE 让从站暴露 Web 诊断页面；AoE 则允许直接读取内部变量。相比之下，PDO 只能反映“当前状态字和实际值”，无法解释“为什么变成这个状态”。所以一个完整的诊断策略，应该是用 PDO 发现异常，用邮箱定位原因。
下面这张表把五类协议的关键属性做了对照，便于在选型和排障时快速判断。
| 协议 | 通道 | 典型用途 | 实时性影响 | 诊断价值 |
|---|---|---|---|---|
| PDO | 过程数据 | 周期输入输出、伺服控制字/状态字 | 直接决定周期与抖动 | 反映当前状态，不解释原因 |
| SDO（CoE） | 邮箱 | 参数读写、对象字典访问、诊断读取 | 短报文，影响小 | 高，可读错误码与诊断历史 |
| FoE | 邮箱 | 固件升级、配置文件下载 | 大文件，需停机窗口 | 中，可回读版本与配置 |
| EoE | 邮箱 | IP 封装、Web 诊断、Telnet | 占用邮箱带宽 | 高，可访问从站 Web 页面 |
| AoE | 邮箱 | ADS 变量访问、服务调用 | 占用邮箱带宽 | 高，可深度访问内部变量 |
一个可复用的排障判断路径
当现场出现“周期抖动变大”或“诊断信息读不到”时，可以按下面的顺序排查，避免在两条车道之间来回猜测。
- 先看 PDO 是否正常：检查工作计数器 WKC 是否等于预期值，若 WKC 不匹配，说明过程数据帧在某个从站丢失或映射不一致，问题在 PDO 通道。
- 再看邮箱是否拥塞：若 WKC 正常但周期抖动大，检查是否有 FoE 升级、EoE 大流量或高频 SDO 读取正在执行，这些会占用邮箱和主站处理时间。
- 最后看诊断来源：若需要定位故障原因，通过 SDO 读取
0x10F3诊断历史或0x603F错误码；若从站支持 EoE，可直接访问其 Web 页面查看更直观的状态。
<Mailbox> 节点下的 <CoE>、<FoE>、<EoE>、<AoE> 子节点直接标明从站支持哪些邮箱协议。选型时先确认这一点，再决定诊断方案，可以避免“设备支持但主站没启用”的常见问题。
总结来说，PDO 和邮箱通信是 EtherCAT 实时性与诊断能力的两条腿：PDO 负责“跑得快”，邮箱负责“看得清”。CoE/SDO 是参数与诊断的主力，FoE 负责文件级维护，EoE 和 AoE 提供更灵活的访问手段。理解它们各自的位置和代价，才能在周期优化和故障定位之间做出正确取舍。