Nearly every joint-module enquiry ends at the same question: CAN or EtherCAT? It is usually asked after the torque is settled, and it should be asked earlier — because the bus quietly decides your control rate, your wiring harness and how much of your integration budget goes into debugging.
This is the short version we work through with customers. It assumes the mechanical side is already close: torque band chosen, envelope known, reduction ratio in the right range. If not, start with the joint module comparison by torque band and come back to the bus afterwards.
What the two buses actually are
CAN is a two-wire differential bus, 1 Mbit/s at the classic 2.0 limit, with 8 bytes of payload per frame and priority-based arbitration: the lowest message ID wins, everyone else waits and retries. Most humanoid joints speak either a vendor-defined CAN protocol or the MIT-style torque mode popularised by the MIT Mini-Cheetah work — command torque, position and gains in one frame, read position, velocity and torque back in another.
CAN FD keeps the arbitration phase at up to 1 Mbit/s and switches to a faster data phase — 2 to 5 Mbit/s is typical in robot hardware — with up to 64 bytes per frame. Same wiring, same tooling, roughly five times the throughput.
EtherCAT is Ethernet at the physical layer (100 Mbit/s) with a different data-link rule: one frame travels out through every slave and back, and each device reads and writes its own slice as the frame passes. The master schedules everything, and distributed clocks align slave time to sub-microsecond jitter, so a whole robot can be updated in a single deterministic cycle.
Head to head
| CAN 2.0 | CAN FD | EtherCAT | |
|---|---|---|---|
| Line rate | ≤1 Mbit/s | 1 Mbit/s arbitration, 2–5 Mbit/s data phase (typical) | 100 Mbit/s |
| Payload per frame | 8 bytes | Up to 64 bytes | One frame carries every axis |
| Arbitration | Priority-based, non-deterministic under load | Same | Master-scheduled, deterministic |
| Synchronisation | None built in | None built in | Distributed clocks, sub-µs jitter |
| Typical control loop | 200–500 Hz (approx.) | 500 Hz–1 kHz (approx.) | 1 kHz; 250–500 µs cycles in high-axis builds |
| Cabling | One twisted pair, 120 Ω terminators at both ends | Same | Industrial Ethernet (RJ45 / M8), tree topology, no switch required |
| Master side | USB-to-CAN adapter, trivial | CAN FD adapter | NIC plus a real-time stack (SOEM, IgH master, TwinCAT) or a dedicated master |
Ranges reflect common practice in humanoid hardware, not a standard. Confirm the figure on the specific datasheet before you design around it.
The bandwidth arithmetic that actually decides it
A CAN 2.0 frame carrying 8 bytes takes roughly 110–130 µs on the wire once bit stuffing is counted. That puts a 1 Mbit/s bus in the order of 5,000–8,000 frames per second in real use — less once error frames, retransmissions and bus load above ~50% are accounted for.
Every axis needs at least one command frame out and one feedback frame back per control cycle. Multiply it out:
| Axes on one bus | 200 Hz | 500 Hz | 1 kHz |
|---|---|---|---|
| 6 (single arm) | 2,400 frames/s — CAN 2.0 | 6,000 — CAN 2.0, tight | 12,000 — CAN FD |
| 12 (two arms) | 4,800 — CAN 2.0 | 12,000 — CAN FD | 24,000 — EtherCAT |
| 20+ (upper body) | 8,000 — CAN FD or split bus | 20,000 — EtherCAT | 40,000 — EtherCAT |
| 30+ (whole humanoid) | 12,000 — split bus | 30,000 — EtherCAT | 60,000 — EtherCAT |
The honest caveat: splitting a robot across three or four CAN segments — legs, arms, hands — is completely normal and is how many shipping humanoids are built. EtherCAT does the same job on one cable with one clock. The question is whether your software team would rather own a bus scheduler or a set of segmented buses.
Latency and jitter — the part that hurts control
- CAN gives the lowest-ID node near-deterministic timing and everyone else whatever is left. As load rises, the spread between the first and last axis widens, and torque control loops that assume a fixed period start to misbehave.
- EtherCAT hands every slave its command in the same cycle. For whole-body control, where a hip and an ankle have to be updated against the same trajectory sample, that matters more than raw bandwidth.
- In practice: a 30-axis EtherCAT loop at 1 kHz is routine. The same axis count on CAN means either a few hundred hertz or several buses — and one clock domain per bus.
Wiring and failure modes
| CAN / CAN FD | EtherCAT | |
|---|---|---|
| Topology | Linear bus with short stubs, terminations at both ends | Any tree; an ordinary switch adds jitter, so avoid one if you can |
| Cable | One differential pair — easy to route through a joint | Four-pair industrial Ethernet; connector quality matters |
| Noise tolerance | Very tolerant, long automotive heritage | Differential too, but less forgiving of poor cabling next to motor phases |
| Single fault | A node that babbles can block the whole bus; bus-off recovery is on you | A break drops every slave behind it; cable redundancy exists on some devices |
| Diagnostics | Error counters and error frames; limited introspection | Working counters, per-slave status, link-loss detection |
What it means when you order
- Protocol is usually a variant, not a different joint. The same mechanics and ratings are often offered with CAN, CAN FD or EtherCAT firmware — but the stocked variant is not always the one you want. Ask which is on the shelf and what the other costs in lead time.
- Ask for the ESI file and object dictionary before committing. EtherCAT drives commonly use CoE (CANopen over EtherCAT), so the CiA 402 profile is familiar, but vendor-specific objects still differ between factories.
- Mixing is normal. EtherCAT for legs and arms, CAN FD for a hand that ships with its own SDK, RS-485 where the hand's own tooling expects it. Budget a gateway or a second master.
- Decide protocol and frame together. Some brake and torque-sensor options are only offered on particular protocol variants, so confirming the bus early avoids a late re-quote.
Rules of thumb
- Under ~10 axes, 200 Hz or slower: CAN 2.0. Cheapest harness, easiest to debug, plenty of margin.
- 10–20 axes with coordinated motion: CAN FD across two segmented buses, or EtherCAT if you already run a real-time master.
- 20+ axes at 1 kHz, or whole-body control: EtherCAT, and standardise on it for the whole build.
- Hands and wrists: use whatever the hand's SDK is designed around. Do not force it onto your main motion bus unless you own the driver.
Whichever way it goes, buy the whole robot on one purchase order so protocols, connectors and spares match across the build — we source across every factory on our brand list, including both harmonic joint variants.
Still deciding? Send us the axis count
Give us axis count, control rate, protocol preference and quantity, and we will shortlist modules that ship in the variant you need — across our partner factories, not one catalogue.
Tell us your bus and axis count
Specs quoted from manufacturer datasheets; final figures confirmed at quotation.