EtherCAT
Why Aether adopts an EtherCAT communication model for deterministic motion control.Written byPhilRayBoy
What Is EtherCAT?
The EtherCAT protocol is used in Aether because it is a real‑time fieldbus that runs over standard Ethernet. A single master transmits a frame that passes through every device. Each device reads and writes its data on‑the‑fly at line rate. The frame then returns to the master carrying the updated process data for that cycle.
EtherCAT supports flexible topologies (line, tree/branch, ring) and typically runs at 100 Mbit/s with deterministic cycle times and low jitter. Distributed Clocks (DCs) synchronize all nodes to a single time base so devices act in lock‑step.
Two paths handle data:
- Fast cyclic process data (PDOs) for real‑time control.
- A separate mailbox channel (SDO) for setup and diagnostics.
This pattern is ideal for multi‑axis motion control: the master commits a schedule, all axes update together, and sensors/encoders are sampled inside the same cycle.
How Aether Uses It
Aether treats MCU and I/O nodes like EtherCAT‑style devices. Cycles are deterministic, I/O is register‑mapped, and devices describe themselves with descriptors for discovery, mapping, and safe defaults. This mirrors mature fieldbus practice and keeps the real‑time path clean and predictable: timing‑critical work runs inside the core while higher‑level logic lives on the controller. A single cable can service multiple axes, I/O blocks, and sensors with consistent timing, and both AetherMCU boards and third‑party EtherCAT devices can share the same bus.
Topology & Power
EtherCAT itself uses the 100BASE-TX ethernet standard, which is easy to implement and use. You can use regular ethernet (RJ45) cables to connect devices together. It is not compatible with standard ethernet gear like routers or switches.
| Topology | Ports Required | Redundancy | Flexibility | Cost | Fault Tolerance |
|---|---|---|---|---|---|
| Line | 2 per device | 🔴 None | 🟡 Low | 💸 Low | 🔴 Poor |
| Tree | 3-4 per branch device | 🟡 Partial | 🟢 High | 💸💸💸 High | 🟡 Medium |
| Star | 2+ per branch device | 🟡 Partial | 🟡 Medium | 💸💸 Medium | 🟢 Good |
| Ring | 2 per device + extra master port | 🟢 Full | 🟢 High | 💸 Low* | 🟢 Good |
Line Topology
A simple daisy-chain where devices connect sequentially. Most cost-effective as each device needs only two ports. Easy to implement, but offers no redundancy — a cable break or device failure disconnects all downstream devices.
Tree Topology
Combines daisy-chain with branch lines using devices with 3-4 ports. More flexible than line topology and offers better fault tolerance — failures on one branch don't affect other branches. Higher cost due to multi-port requirements.
Star Topology
Uses EtherCAT branch devices to create star-like connections. Device failures or cable breaks on one branch don't disconnect other devices. Maintains full real-time capabilities with the logical ring. Higher flexibility and fault isolation than tree, but requires infrastructure devices.
Ring Topology
Connects the last device back to the master for cable redundancy. If any single cable breaks, communication continues via the alternate path. Requires all devices including the master to have a second network port. Adds redundancy without adding infrastructure cost, if your master has a second port.
Timing Targets
Distributed Clocks provide deterministic cycles. On the host, real‑time scheduling helps meet tight time budgets.
Why should I use EtherCAT (instead of CAN, UART, USB, ...)?
Under load, EtherCAT maintains deterministic timing because a single synchronized frame flows through every device. CAN arbitration, UART’s point‑to‑point bandwidth limits, and USB’s host‑scheduled microframes introduce jitter and queuing, which complicates precise motion control.
| Protocol | Transport | Bandwidth | Determinism under load | Global time base | Payload model | Topology |
|---|---|---|---|---|---|---|
| EtherCAT | 🟢 Ethernet | 🟢 100 Mbit/s+ | 🟢 High | 🟢 Yes (DCs) | 🟢 Hybrid | 🟢 Multiple |
| CAN(-FD) | 🟡 Differential | 🟡 1–8 Mbit/s | 🟡 Medium | 🔴 No | 🔴 Small frames | 🟢 Multiple |
| UART | 🔴 Point‑to‑point | 🔴 9.6–921 Kbit/s | 🔴 Low | 🔴 No | 🔴 None | 🔴 1:1 |
| USB | 🟡 Host‑scheduled | 🟢 12–480 Mbit/s | 🟡 Low–Medium | 🔴 No | 🟡 Packets | 🟡 Star |
For printers and robotics, that determinism translates into crisp phase alignment across axes and predictable sampling windows for sensors and encoders. CAN and UART still fit slow or legacy peripherals where strict phase alignment is not required. USB remains convenient for early development and for host‑centric devices before EtherCAT hardware lands.
Frequently Asked Questions
Last updated on