设备通信与协议编程（九）：EtherCAT 周期通信、分布式时钟与软件边界

EtherCAT 使用标准以太网物理层，却不是“把设备接到交换机后用 TCP 发命令”。它面向确定性的周期过程数据：MainDevice 构造帧，SubDevice 在帧经过时直接读取或写入对应数据区域，并由专用控制器完成高速处理。

本文讨论上位机开发者需要理解的模型，不替代主站协议栈、设备 ESI 和 ETG 规范。

1. 为什么普通以太网直觉会失效

EtherCAT 帧使用 EtherType 0x88A4，通常不经过 TCP/IP。一个帧可携带多个 EtherCAT datagram；SubDevice 在帧流经时“on the fly”处理相关数据，末端再利用全双工链路返回 MainDevice。

因此常规企业交换网络、Socket API 和 IP 地址不是其周期数据路径。拓扑、网卡、驱动与主站栈必须按 EtherCAT 系统设计。

主站启动时根据配置把各 SubDevice 的过程数据映射到逻辑过程映像。实时任务通常按固定周期执行：

1
2
读取上一周期输入 → 执行控制算法 → 写入输出过程映像
→ 发送/接收 EtherCAT 帧 → 检查 Working Counter 与状态

PDO 表示周期过程数据映射；参数和诊断常通过 mailbox 协议访问，例如 CAN application protocol over EtherCAT（CoE，复用上一篇 CANopen 的对象字典与 SDO/PDO 机制）中的 SDO。周期 PDO 与非周期邮箱流量应分别预算。

典型状态包括：

1
INIT → PRE-OP → SAFE-OP → OP

具体转换条件、错误确认和安全输出由设备实现及 profile 决定。总线进入 OP 也不等于设备业务状态已 Ready。

每个 datagram 带 Working Counter（WKC），SubDevice 成功执行相关内存操作时按规则更新。主站将实际 WKC 与配置期望值比较，可发现节点缺失或操作未被处理。

WKC 正确只能证明本周期总线访问符合预期，不能证明伺服已到位、气缸已动作或工艺已经完成。这些仍要通过状态字、反馈量和设备状态机判断。

Distributed Clocks（DC）让支持 DC 的 SubDevice 本地时钟对齐到共同系统时间，并补偿传播延迟。动作可由本地 SYNC 信号触发，而不是依赖帧恰好到达的时刻，从而降低通信抖动对同步动作的影响。

ETG 资料给出可达到显著低于 1 µs 的同步抖动，但这是协议与合格实现的能力描述，不是任意 PC、拓扑和配置下自动获得的端到端控制精度。实际系统还受控制任务抖动、采样、驱动器和机械响应影响。

ETG 说明 MainDevice 可使用标准 Ethernet MAC；但周期是否确定还取决于：

在 Windows/WPF 线程里用普通定时器每 1 ms 调一次 SDK，不等于建立了 1 ms 硬实时控制。

1
2
3
4
5
6
7
UI / Recipe / 流程编排
        ↓ 非实时命令、状态快照
实时控制进程或主站运行时
        ↓ 固定过程映像、无阻塞周期任务
EtherCAT 主站栈与网卡驱动
        ↓
SubDevices

实时侧避免动态分配、阻塞 I/O、同步日志和不可控回调。上位机通过共享内存、IPC 或厂商 API 获取降采样状态，并携带周期号、DC 时间和质量状态；UI 卡顿不能阻塞总线周期。

ESI（EtherCAT SubDevice Information）是厂商提供的 XML 设备描述，包含身份、对象、过程数据映射和同步能力。配置工具基于网络扫描和 ESI 生成主站配置；部分生态将最终网络配置表示为 ENI。

生产系统应版本化保存：

现场设备修订变化时，不能只看节点顺序相同就直接运行。

至少观察：

日志应放在非实时路径，通过预分配环形缓冲传递摘要；不要在周期回调里格式化大段字符串。Wireshark 自带 EtherCAT 协议解析器，可直接查看帧中的 Working Counter 与命令明细。

EtherCAT 的价值在于高效的 on-the-fly 过程数据交换和分布式同步，但实时性是整条系统链路的属性。上位机应把硬实时周期与 UI、日志、流程编排隔离，并用 WKC、DC 和状态反馈分别判断总线健康、同步质量与业务结果。