Integrated servo joints moved the current, velocity, and position loops into the joint itself. What's left on the wire is coordination: setpoints going down, feedback coming up, every cycle, for every axis. The bus determines how fast and how deterministically that happens, which in turn determines what kind of machine you're allowed to build. Our joints ship with EtherCAT, CANopen, CAN/CAN-FD, and RS-485 options across the range, so this is a genuine choice, not a spec-sheet accident.
What actually differs
| Property | EtherCAT | CANopen (classic CAN) | CAN-FD |
|---|---|---|---|
| Bandwidth | 100 Mbit/s | 1 Mbit/s | Up to ~5 Mbit/s data phase |
| Practical cycle time | ≤1 ms, tens of axes | 5–20 ms, handful of axes | 1–5 ms, several axes |
| Synchronisation | Distributed clocks, sub-µs | SYNC message, ~ms class | SYNC message, improved by bandwidth |
| Topology | Line/ring, standard Ethernet cable | Single twisted pair, multidrop | Single twisted pair, multidrop |
| Controller cost | Master stack or motion controller | Any MCU with CAN | MCU with CAN-FD (now common) |
All three speak the same application language on our joints: the CiA 402 drive profile, with Profile Position, Profile Velocity, Profile Torque, and the cyclic synchronous modes. The difference is which of those modes the bus can actually feed.
The question that decides it: where does interpolation live?
In profile modes, you send a target and the joint plans its own trajectory. The bus only needs to deliver occasional commands; classic CAN handles this comfortably. In cyclic synchronous modes (CSP/CSV), the controller streams a fresh setpoint every cycle and the axes follow in lockstep: this is how a six-axis arm draws a straight line through space. That streaming needs short, deterministic cycles and tight clock sync across axes.
Where each one earns its place
EtherCAT is the default for coordinated machines: arms, gantries, humanoid limbs, anything where the motion of one joint is meaningless without the others. Sub-millisecond cycles with distributed clocks mean the wrist and shoulder receive their setpoints for the same instant. The cost is a real EtherCAT master: a motion controller or an industrial PC with a proper stack.
CANopen remains the honest workhorse for machines of a few independent axes: indexers, positioners, lab automation, door-and-turret mechanisms. Any microcontroller has CAN; the wiring is one twisted pair daisy-chained through the machine; the tooling is mature. Its ceiling is arithmetic: at 1 Mbit/s, streaming cyclic setpoints to many axes at short cycles simply doesn't fit.
CAN-FD raises that ceiling severalfold while keeping CAN's wiring and controller simplicity, which is exactly why compact and mobile robotics adopted it. Our lightweight magnesium joints run CAN/CAN-FD natively: on a battery-powered arm where the controller is an embedded board and every gram of cabling counts, CAN-FD delivers multi-axis coordination without an industrial Ethernet stack.
RS-485/Modbus, available on our smaller rotary actuator sizes, is the bench-and-commissioning port: single-axis setup, parameter tuning, acceptance testing, not a machine bus.
Decision rules
- Interpolated multi-axis motion, or controller-closed force loops → EtherCAT, no debate.
- Up to ~6 independent point-to-point axes, cost-sensitive controller → CANopen.
- Compact/mobile machine, embedded controller, moderate coordination → CAN-FD.
- Mixed machine? Put the coordinated mechanism on EtherCAT and auxiliary axes on CAN; gateways are cheaper than over-speccing every joint.
- And decide before ordering: the bus option is a variant of the joint, not a firmware toggle.
If you tell us the axis count, the coordination requirement, and what's running the machine, we'll spec the bus variant with the sizing, same working day, as usual.
Related: One encoder or two? · Choosing a robot-joint reducer.