运动控制中的通信协议：实时以太网对比从一次产线停摆说起去年秋天，我在苏州一家3C电子厂的产线上被紧急叫过去。现场情况是：六轴机器人配合视觉系统做高速分拣，节拍要求每分钟120次。设备商用的是EtherCAT总线，但现场调试时发现，当视觉系统触发拍照的瞬间，机器人末端会出现肉眼可见的抖动，偶尔还会丢步。示波器抓了总线波形，发现EtherCAT数据帧在视觉触发时刻出现了大约200微秒的延迟抖动——这个抖动在普通工业以太网里根本不算事，但在运动控制里，200微秒足够让伺服驱动器的位置环产生一次明显的过冲。后来排查发现，问题出在交换机上。现场为了布线方便，在EtherCAT主站和从站之间串了一台普通工业交换机。EtherCAT的“集总帧”机制要求数据帧在从站之间“飞过”时不能有存储转发延迟，普通交换机的MAC层处理会引入不可预测的延迟。换掉交换机，改成EtherCAT专用的菊花链拓扑，抖动直接降到5微秒以内。这个案例让我意识到，很多工程师对实时以太网的理解还停留在“能通就行”的层面，而运动控制对通信的要求，远比“通不通”要苛刻得多。实时以太网到底在“实时”什么先别急着对比协议，得搞清楚运动控制场景下“实时”的具体含义。我们做伺服驱动的人都知道，位置环的更新周期通常在50微秒到1毫秒之间，速度环和电流环更快。如果通信延迟超过一个控制周期，驱动器就会“饿死”——没有新的指令数据，只能沿用上一周期的值，这在高速运动中会导致明显的跟踪误差。实时以太网要解决的核心问题有三个：确定性延迟、低抖动、高
