CAN FD vs CAN XL vs CANopen: Industrial and Robot Bus Selection (2026)

Most engineers compare CAN FD vs CAN XL as if they were two speed grades of the same wire, and then lose weeks because the real decision sits one layer up. CAN FD and CAN XL are data-link protocols. CANopen is an application layer that rides on top of either Classical CAN or CAN FD. Choosing between them means choosing a frame format, an object dictionary, a physical layer and a real-time budget, and those four choices constrain each other more than any datasheet bit-rate suggests.

This matters now because CAN XL is standardised in ISO 11898-1:2024, SIC XL transceivers are specified in CiA 610-3, and humanoid and mobile-robot builders are choosing joint buses with 30 or more actuators. A 1 kHz control loop over Classical CAN stops fitting at around four joints, and the usual escape route, EtherCAT, brings its own cost and topology. This post gives you the frame-level facts, a worked bus-load calculation, the termination rules that decide whether the higher bit rates work, and a decision tree you can defend in a design review.

What this covers: the frame formats and standards of Classical CAN, CAN FD, CAN XL and CANopen (CiA 301, CiA 402, CiA 1301); a worked joint-bus load example; physical-layer limits and SIC transceivers; a SocketCAN snippet; and when EtherCAT is the better answer.

Context and Background

Classical CAN, defined by Bosch in the 1980s and standardised as ISO 11898, carries up to 8 data bytes per frame at up to 1 Mbit/s. Its defining feature is bitwise arbitration: every node transmitting at the same instant drives the bus, dominant bits override recessive bits, and the node with the numerically lowest identifier wins without destroying the frame. That property gives CAN deterministic worst-case latency for the highest-priority message, which is why it survived forty years in vehicles, elevators, packaging machines and drives.

The constraint is the same property. Arbitration requires every node to see every bit within one bit time, so the bit time is bounded by round-trip propagation along the cable and through the transceivers. You cannot simply clock the whole frame faster. CAN FD (flexible data rate), specified in ISO 11898-1:2015, works around this by running arbitration at the nominal rate and then switching to a faster rate for the data portion, once only one node is transmitting and nobody needs to see the bit within the same bit time. Payload grows to 64 bytes. CAN XL pushes the same idea further: priority arbitration at the nominal rate, then a fast phase with a different signalling scheme and payloads up to 2048 bytes.

CANopen is a separate axis. Maintained by CAN in Automation (CiA), the CiA 301 application-layer specification defines the object dictionary, the Process Data Object (PDO) for cyclic real-time data, the Service Data Object (SDO) for configuration, and network management (NMT), SYNC, EMCY and heartbeat services. Device and drive behaviour sits in profiles such as CiA 402 for drives and motion control. CANopen FD (CiA 1301) rebuilds this stack for the CAN FD data link, and CiA’s own description names the Universal Service Data Object (USDO) as the most significant change from classic CANopen.

If you are weighing this against Ethernet-based options, our comparison of PROFINET, EtherCAT and OPC UA FX over TSN covers the other side of the decision. The CiA overview of CAN XL is the primary source for much of the frame-level detail below: CAN in Automation: CAN XL.

Three layers people conflate

It helps to name the layers before comparing them. The physical layer (ISO 11898-2) defines transceivers, differential voltage levels and termination. The data-link layer (ISO 11898-1) defines frames, arbitration, error detection and bit timing. The application layer (CANopen, J1939, DeviceNet-style stacks) defines what the bytes mean. A claim like “CANopen is slower than CAN FD” is a category error: CANopen on CAN FD inherits the CAN FD rate. A claim like “CAN XL replaces CANopen” is also wrong: CAN XL has no object dictionary, and a CANopen-like layer would have to be defined over it. As of the sources I reviewed, CiA’s CAN XL higher-layer work (CiA 611) defines service data unit types and an addressing model, but I did not find a published CANopen-over-CAN-XL profile, so treat that as unavailable rather than imminent.

CAN FD vs CAN XL: The Reference Comparison

Short answer: CAN FD raises the payload to 64 bytes and speeds up the data phase, typically to 2 to 8 Mbit/s depending on transceivers and topology. CAN XL raises the payload to 2048 bytes, separates priority from addressing, and uses a different signalling scheme in the data phase for 20 Mbit/s and beyond. CANopen is not a competitor to either: it is the application layer you choose to run on Classical CAN or CAN FD.

Figure 1: Protocol lineage. Classical CAN branches into CAN FD and CANopen; CAN FD carries CANopen FD (CiA 1301); CAN XL adds Ethernet-oriented services; CiA 402 drive profiles reach the joint bus through CANopen or EtherCAT CoE.

Figure 1 shows why the question “which bus?” really contains two questions: which data-link layer, and which application layer. The only combination with a published, mature profile ecosystem for drives is CiA 402 over CANopen (Classical CAN) today; CANopen FD brings the same style of profile to CAN FD, and CAN XL targets a different set of jobs, discussed below.

Classical CAN: the baseline

A Classical CAN base frame has an 11-bit identifier, a 4-bit data length code, up to 8 data bytes and a 15-bit CRC. The no-stuffing length of an 8-byte base frame is 111 bits including a 3-bit interframe space; the worst case with bit stuffing (a stuff bit after five identical bits) is 135 bits. At 1 Mbit/s that is 111 to 135 microseconds per frame, and the figure we will reuse in the load example. The extended format uses a 29-bit identifier, the basis for SAE J1939.

Classical CAN has no fast phase, no payload beyond 8 bytes and no cryptographic or fragmentation support. Higher layers (ISO-TP, ISO 15765-2, or CANopen segmented SDO) add transport on top and cost throughput.

CAN FD: two bit rates in one frame

CAN FD is specified in ISO 11898-1:2015 and is backward-compatible on the wire with Classical CAN in the sense that FD frames can share a bus with Classical frames provided every node is at least FD-tolerant. A node that only understands Classical CAN will flag FD frames as errors, so the mix is only safe if legacy nodes are removed or FD-passive.

Three control bits matter. FDF (FD format) marks the frame as CAN FD. BRS (bit rate switch) tells receivers to change to the data bit rate after the BRS bit. ESI (error state indicator) tells receivers whether the transmitter is error-active or error-passive. The DLC values above 8 map non-linearly: 9 to 12 bytes, 10 to 16, 11 to 20, 12 to 24, 13 to 32, 14 to 48, 15 to 64.

The error detection also changed. CAN FD uses a CRC-17 for payloads up to 16 bytes and a CRC-21 for larger payloads, and adds a stuff-count field plus fixed stuff bits inside the CRC field, which closes a stuff-bit error hole that the longer data field would otherwise worsen. The combination is why you cannot reuse a Classical CAN controller design by simply widening the buffer; the CRC and framing logic are different.

The CAN FD bit rate story is more nuanced than the 8 Mbit/s headline. The arbitration phase remains bounded by the same propagation constraint as Classical CAN, so nominal rates stay at 1 Mbit/s in most systems (a 2 Mbit/s nominal rate is possible on short, clean buses). The data phase is commonly quoted at 2 to 5 Mbit/s with conventional transceivers (CiA’s CANopen FD announcement cites transceivers qualified up to 5 Mbit/s), and up to 8 Mbit/s with SIC transceivers per the TI application note on SIC, depending on topology. Texas Instruments also notes that regular CAN FD transceivers rated for 5 Mbit/s are often limited to under 2 Mbit/s in real vehicle networks because of ringing on complex topologies; that is the practical gap between datasheet and bus.

Why the fast phase works at all

During arbitration, every node must sample the same bit, so the bit time must exceed round-trip delay. Once arbitration is won, only one node transmits, so the receivers only need to sample the transmitter’s bits at the end of each bit time; propagation delay becomes a fixed offset rather than a limit. That is the entire trick in CAN FD, and it is why the data-phase rate depends on the quality of the sample-point placement and the transceiver’s loop-delay symmetry, not on the arbitration bit time. A CAN FD controller also implements transmitter delay compensation (TDC), which measures the loop delay from TXD to RXD and shifts the secondary sample point accordingly; in practice it becomes necessary once data-phase bit times shrink toward the loop delay (a rule of thumb, not a spec threshold).

Figure 2: Phases of a CAN FD frame with bit rate switch. Arbitration and ACK stay at the nominal rate; only the section between BRS and the CRC delimiter runs at the data rate.

Figure 2 makes the cost structure visible: whatever you do in the data phase, the arbitration header and the ACK/EOF trailer are always paid at the nominal rate. For small payloads such as an 8-byte PDO, the nominal part dominates the frame time, and raising the data rate buys less than the datasheet suggests. For 64-byte payloads the data phase dominates and the speed-up approaches the ratio of rates. That asymmetry drives the bus-load results later.

CAN XL: priority first, then a different physical mode

CAN XL is standardised in ISO 11898-1:2024 and specified by the CiA SIG CAN XL in the CiA 610 series (protocol and test plans), CiA 611 (higher-layer services), CiA 612 (guidelines) and CiA 613 (add-on services). CiA states that the group has worked on it since December 2018. The data field runs from 1 to 2048 bytes in one-byte steps, so there is no stepped DLC table like CAN FD’s.

The structure differs from CAN FD in three ways that matter to a system architect.

First, priority is separated from addressing. Arbitration still uses an 11-bit priority identifier at the nominal bit rate. Addressing and content identification move into a 32-bit acceptance field (AF) that is part of a 64-bit hardware acceptance filter. In CAN FD and Classical CAN the identifier does both jobs, which is why CANopen COB-IDs encode both the function code and the node ID and why you run out of clean ID space. Some secondary articles describe a PCP (priority code point) field; the CiA page I checked describes the 11-bit priority ID and does not use the PCP term, so I do not rely on it here.

Second, the control section carries an 8-bit SDU type (SDT), analogous in intent to an EtherType, with values defined in CiA 611-1, and an 8-bit virtual CAN network ID (VCID) that supports up to 256 logical networks on one physical segment. A SEC bit marks use of CANsec (CiA 613-2, listed by CiA as under development at the time of the page I read), which adds a 4-byte header and a 16-byte trailer holding the authentication tag. Fragmentation support (CiA 613-3, also listed as under development) lets high-priority frames interrupt long frames of 128 to 2048 bytes and resume them. That addresses CAN XL’s own worst case: a 2048-byte frame at 20 Mbit/s occupies the bus for roughly 820 microseconds of data time alone (16,384 bits divided by 20 Mbit/s), which is a long time to block a motor command.

Third, the data phase changes the signalling. At the end of arbitration the bit rate switches from nominal to the XL data rate at the boundary between the ADH bit and the DH1 bit in the ADS field, and switches back at the boundary between the FCP(0) bit and the DAH bit in the DAS field. In the fast phase the bus driver uses push-pull drive of level 0 and level 1 instead of dominant and recessive, and the receiver thresholds change; CiA describes the PWM coding that makes bit rates of 20 Mbit/s and higher possible depending on the physical network. CAN SIC XL transceivers (CiA 610-3) are needed for rates of 20 Mbit/s and beyond; CiA also notes that CAN XL can use ISO 11898-2 high-speed or CiA 601-4 SIC transceivers, which implies lower rates on those parts. The transceiver maps arbitration to SIC mode, data transmission to FAST TX mode and data reception to FAST RX mode, and when transceiver mode switching is enabled (a local configuration), the durations of the ADH and DAH bits signal the change.

Figure 3: CAN XL frame flow. Arbitration runs at the nominal rate in SIC mode; the transceiver then enters FAST mode for the XL data phase, protected by a 32-bit frame CRC that cascades over a 13-bit preface CRC.

Figure 3 shows the integrity design. A 13-bit preface CRC (PCRC) in the control field protects the header, and a 32-bit frame CRC (FCRC) cascades over the whole frame including the PCRC. CiA states both detect any five randomly distributed bit errors, a Hamming distance of 6. That is a stronger guarantee than Classical CAN’s, and it matters for 2048-byte frames where a single weak CRC would be the weak link.

What CAN XL is for, and what it is not for

CAN XL is widely described, including in CiA material, as sitting between CAN FD and 100BASE-T1 Ethernet (my paraphrase, not a quoted CiA sentence): a bus that keeps CAN’s arbitration and multidrop wiring but can carry packets large enough to tunnel Ethernet frames (the SDT field plays the role of EtherType). That positioning is explicitly an in-vehicle and zonal-architecture story. For industrial robots the benefit is more modest: one 2048-byte frame can carry a firmware chunk or a point-cloud tile, but a 1 kHz joint control loop needs short, frequent frames, and I could not verify a header-length advantage for CAN XL. For small cyclic payloads the extra bit rate may not translate into shorter frame times, because the arbitration phase still runs at the nominal rate. I could not find published CAN XL joint-controller benchmarks, so any claim that CAN XL “wins” the joint bus is unverified.

Hardware availability is the other practical limit. As of the sources I read, CiA lists specifications and transceiver requirements, but I could not verify a production-volume, general-availability controller ecosystem comparable to CAN FD’s, so confirm silicon and tooling availability with vendors before committing a design.

CANopen, CiA 402 and CANopen FD

CANopen is where most industrial and robot drive integrations actually live, so it deserves the same mechanism-level treatment as the data-link layers.

CiA 301: the object dictionary and its services

Every CANopen device exposes an object dictionary: a table addressed by a 16-bit index and an 8-bit subindex. Communication parameters live in the 0x1000 range, manufacturer-specific objects in 0x2000, and standardised device-profile objects (for example the CiA 402 drive profile) in 0x6000. The CiA 301 specification defines the services that move that data.

• NMT (network management) moves devices through Initialising, Pre-operational, Operational and Stopped states. PDOs flow only in Operational.
• PDO (process data object) carries cyclic real-time data. It has no protocol overhead beyond the identifier: the meaning of each byte is fixed by PDO mapping, a configurable list of object dictionary entries. Triggering can be event-driven, timer-driven or SYNC-driven.
• SDO (service data object) is a confirmed client-server access to any object, used for configuration and diagnostics. Expedited transfers move up to 4 bytes; segmented and block transfers move more at the cost of many frames.
• SYNC is a single, high-priority frame that triggers synchronous PDO sampling and actuation across nodes.
• EMCY and heartbeat report faults and liveness; a heartbeat consumer can detect a silent node.

The default COB-ID scheme in the predefined connection set allocates the 11-bit identifier as a 4-bit function code and a 7-bit node ID, which limits a network to 127 nodes and fixes the priority order: NMT and SYNC at the top, then EMCY, then PDOs, then SDOs and heartbeat. Because the function code sits in the high bits, all TPDO1 frames out-prioritise all RPDO1 frames across nodes regardless of urgency, a property you can override by remapping COB-IDs but should understand before you do.

CiA 402: why drives choose CANopen

CiA 402 (the drives and motion control profile, also published through IEC 61800-7) defines a state machine driven by a 16-bit controlword and reported through a 16-bit statusword, plus operating modes such as profile position, profile velocity, cyclic synchronous position, cyclic synchronous velocity and cyclic synchronous torque. The cyclic synchronous modes are the ones relevant to robots: the master computes the trajectory and each cycle writes a target position, velocity or torque via RPDO while reading the actual position, velocity or torque via TPDO. The standard PDO payload for a servo is a handful of bytes: a 16-bit controlword, a 32-bit target position, a 16-bit torque limit, versus a 16-bit statusword, a 32-bit actual position and a 16-bit torque value. That fits into 8 bytes with a little care, which is exactly why Classical CAN and CANopen dominated the previous generation of servo drives.

The portability argument is strong. CiA 402 objects are also exposed over EtherCAT through the CAN application protocol over EtherCAT, usually written CoE, so a drive firmware and a master application written to CiA 402 can move between CAN and EtherCAT with the transport changed but the object model intact. The comparison in our earlier post on deterministic Ethernet options shows the Ethernet side of the same story.

CANopen FD (CiA 1301)

CiA released CANopen FD as CiA 1301, the application layer and communication profile for CAN FD. CiA’s announcement states that it runs on the CAN FD data link layer, that frames carry up to 64 bytes, that it is optimised for front-end control, and that it provides enough bandwidth for more than 80 percent of commercial control applications (a CiA claim, not an independent measurement). The announcement also states that CAN FD hardware is priced about the same as Classical CAN hardware, which, again, is a vendor-organisation claim; check current quotes.

The biggest change is the Universal Service Data Object (USDO). It supports broadcast and unicast communication and access to nodes in other network segments through routing, unlike classic SDO’s single client-server pair per channel. In practice that removes the main commissioning bottleneck of classic CANopen: on a 30-axis robot, uploading parameters through 30 SDO channels serially is slow, and the USDO model is designed to reduce that. I did not find enough detail in the sources I could fetch to describe USDO frame layout, PDO mapping limits in CiA 1301, or any backward-compatibility rules with CiA 301; treat those as items to read from the specification itself.

Classic CANopen and CANopen FD networks cannot be mixed on one segment without gateways in the general case, because Classical CAN controllers do not tolerate FD frames. This is why migration paths usually go through a gateway or a clean new network, not an in-place upgrade.

Figure 4: A defensible selection flow for a robot joint bus or fieldbus segment, from real-time and payload requirements down to ecosystem constraints.

Figure 4 encodes the argument of this post: start from the control-loop budget, then payload, then ecosystem. The final two leaves (CANopen or CANopen FD versus raw CAN FD with SIC transceivers) are separated by whether you want an existing object dictionary and profile ecosystem or are happy to define your own messages.

Worked Example: Bus Load on a 12-Joint Robot at 1 kHz

Datasheets quote bit rates; designers need frame times. The calculation below is my own arithmetic, not a vendor benchmark, and it deliberately uses simple assumptions so you can reproduce it.

Scenario. A 12-joint legged robot or dual-arm manipulator. Every 1 ms each joint receives one command PDO (8 bytes: controlword, target position, torque limit) and sends one status PDO (8 bytes). That is 24 frames per millisecond. SYNC, heartbeats, EMCY and SDO traffic are ignored, which flatters every result. Base 11-bit identifiers are used.

Classical CAN at 1 Mbit/s. An 8-byte base frame takes 111 bit times without stuffing (3-bit interframe space included) and up to 135 with worst-case stuffing, from the standard bit-count formula. Twenty-four frames need 24 x 111 = 2,664 microseconds per 1,000 microseconds available: 266 percent load. Even four joints (8 frames, 888 microseconds, 89 percent) leave no margin once stuffing and a SYNC are added. Classical CAN fits three to four joints at 1 kHz, not twelve.

CAN FD, 1 Mbit/s nominal and 5 Mbit/s data, 8-byte payload. The nominal portion is about 17 bits before the data phase begins plus 12 bits of ACK, EOF and interframe space, 29 bits at 1 microsecond each. The data portion is 97 bits (ESI, DLC, 64 data bits, stuff count, CRC-17 with fixed stuff bits, CRC delimiter) at 0.2 microsecond each, 19.4 microseconds. The frame takes about 48.4 microseconds, so 24 frames need roughly 1,162 microseconds: 116 percent. The 5 Mbit/s data rate helps, but the slow arbitration header still dominates, which is exactly what Figure 2 predicts.

CAN FD, 2 Mbit/s nominal and 8 Mbit/s data, 8-byte payload. The nominal part is 29 bits at 0.5 microsecond, 14.5 microseconds; the data part is 97 bits at 0.125 microsecond, 12.1 microseconds. The frame takes about 26.6 microseconds and 24 frames need about 638 microseconds: 64 percent. Worst-case stuffing in the arbitration and data fields pushes this toward 75 to 80 percent. This needs a short, well-terminated, SIC-quality bus, so it is a topology claim as much as a bit-rate claim.

CAN FD packing: one frame per cycle. A better way to cut the load is to stop sending 24 frames. Packing all 12 joints’ commands into one 64-byte frame (12 joints x 5 bytes = 60 bytes) and receiving statuses in a second frame cuts overhead sharply. At 1 Mbit/s nominal and 5 Mbit/s data, one 64-byte frame takes about 139 microseconds (29 nominal bits plus 549 data-phase bits at 0.2 microsecond), so two frames take about 278 microseconds, or 28 percent load, with about 165 microseconds per frame under worst-case stuffing in the data field (330 microseconds for both). The cost is architectural: a single master frame couples all joints, and a joint cannot be hot-swapped or independently timed. Classic CANopen’s one-PDO-per-node model gives way to a custom or CiA 1301 mapping of multiple nodes’ data.

Configuration	Frame time (8 B payload)	24 frames per 1 ms	Verdict
Classical CAN 1 Mbit/s	111 us (135 worst)	266%	Does not fit
CAN FD 1M/5M	about 48 us	116%	Does not fit
CAN FD 2M/8M	about 27 us	about 64% (75-80% stuffed)	Fits, thin margin
CAN FD 1M/5M, two packed 64 B frames	about 139 us each	about 28% (33% stuffed)	Fits, coupled design

All figures are computed from bit counts, ignore clock tolerance and inter-frame jitter, and are illustrative. Run a real bus-load measurement (candump statistics or a hardware analyzer) before committing.

The lesson for CAN XL

Run the same exercise for CAN XL and the main result is that big frames help and small frames do not. A 2048-byte payload is 16,384 data bits, about 820 microseconds at 20 Mbit/s before any header, so XL is a bulk-transfer and tunnelling tool. A joint loop wants dozens of short frames, where the nominal-rate header dominates. Packing 12 joints into one XL frame is possible, but then you have rebuilt a master-slave frame bus and are in EtherCAT’s territory, with a CAN-style priority arbiter that no longer contributes.

Why EtherCAT keeps winning the multi-axis cases

EtherCAT (IEC 61158 and IEC 61784-2 profile family) works differently: a master sends one Ethernet frame that passes through every slave, each of which reads its outputs and inserts its inputs on the fly, so one frame carries all joints’ data. The bit rate is 100 Mbit/s over standard Ethernet PHYs, and cycle times in the tens of microseconds to hundreds of microseconds are normal in servo systems (vendor-reported; they depend on node count and frame size). The price is a master with real-time Ethernet access, a line or ring topology instead of a multidrop bus, a per-slave ASIC or FPGA core, and distributed-clock configuration. For 30 or more joints with sub-millisecond loops, those costs are usually paid, and CoE keeps the CiA 402 object model so the application code survives.

Physical Layer, Topology and Termination

Bit rate is the last thing to choose and the first thing to fail. Higher data rates shrink the bit time until reflections matter, and CAN’s multidrop topology is exactly the topology that creates them.

Termination and topology rules

A CAN bus is a linear trunk with a 120 ohm termination resistor at each end, giving about 60 ohms measured between CANH and CANL on a powered-down bus with both terminators present. Stubs from the trunk to each node must be short, and the permissible length shrinks as the data rate rises. A common starting point for Classical CAN at 1 Mbit/s is a trunk of around 40 metres with stubs under 0.3 metres; these are rule-of-thumb values from CiA and transceiver guidance, so check the current CiA 303-1 recommendations for your cable. For CAN FD data phases at 5 Mbit/s the bit time is 200 nanoseconds, so a stub of a few centimetres is the safe design, and a star with unterminated branches is the classic failure.

That is the problem CAN SIC (signal improvement capability) addresses. In a regular transceiver the driver’s differential output impedance jumps to about 60 kilohms at the dominant-to-recessive edge, creating an impedance mismatch that rings. Texas Instruments describes the SIC mechanism as detecting the edge on TXD and actively driving the bus recessive for a limited time (maximum 530 ns for tSIC_TX_base) with roughly 100 ohm output impedance, then returning to passive recessive. SIC is specified in CiA 601-4 and integrated into ISO 11898-2:2024 as the Set C mode. TI also reports a loop delay of at most 190 ns for SIC versus 255 ns for regular CAN FD transceivers, and says SIC can reach 8 Mbit/s and share a bus with regular CAN FD and high-speed CAN nodes. Treat the 530 ns window as a constraint too: ringing suppression is bounded to that window, which limits arbitration speed on very long networks.

A practical robot rule: treat each limb as a short trunk with a terminator at the far end, and avoid daisy-chaining through connectors with more than a few centimetres of unshielded pigtail. A humanoid arm with a CAN FD segment and EtherCAT backbone to the torso is a common pattern, but I could not find a primary public source documenting any specific humanoid’s bus architecture, so the pattern is my observation, not a verified fact about a named product.

Differential signalling, grounding and EMC

Shielded twisted pair with the shield grounded at one point (or via capacitors at the others) reduces common-mode noise from servo drives. Isolated transceivers are typically needed when ground potential differs between a power stage and controller, and their propagation delay eats into the budget at the data rate. Common-mode chokes are standard in CAN FD designs; the data-phase edges are fast enough to need them.

Error handling that surprises robot teams

CAN’s error confinement (transmit and receive error counters, error-active, error-passive and bus-off states) protects the bus from a babbling node but also takes a joint offline at 256 transmit errors. In a robot, bus-off means a dead actuator. Configure automatic recovery deliberately (a bus-off recovery of 128 occurrences of 11 recessive bits is the default behaviour in the standard), and supervise with heartbeat so the safety controller decides what a dropped joint means. CAN is not a functional-safety channel on its own; safety protocols such as CANopen Safety (EN 50325-5) layer additional checks on top.

Application Layers Beyond CANopen: J1939 and Custom Protocols

SAE J1939 uses 29-bit identifiers that encode priority (3 bits), a parameter group number and a source address, and is the dominant layer in heavy vehicles and off-highway machinery. J1939 commonly runs at 250 kbit/s (J1939-11) or 500 kbit/s (J1939-14), and its transport protocol fragments messages up to 1,785 bytes into 8-byte frames. If a robot platform includes an engine or hydraulic controller from agricultural or construction equipment, expect J1939 on that segment and a gateway into CANopen or ROS 2 on the robot side. CAN FD extensions for J1939 exist (J1939-22) but check their status with SAE before relying on them; I did not verify them this run.

Many robot builders skip standard layers entirely: a fixed-ID CAN FD frame format, a vendor-specific motor protocol, and a ROS 2 hardware interface on the host. That is a legitimate choice for closed systems, and our walk-through of the ros2_control hardware interface shows where such a bus driver plugs into the control stack. The trade-off is the loss of tooling: no EDS files, no standard configuration tool, and no interoperability with third-party drives.

SocketCAN and python-can: A Minimal Working Example

On Linux, CAN controllers appear as network interfaces through SocketCAN. The commands below bring up a CAN FD interface with a 1 Mbit/s nominal and 5 Mbit/s data rate and enable transmitter delay compensation. Check your controller’s driver documentation for supported keys.

# bring up a CAN FD interface (adapter-dependent; requires CAN FD capable hardware)
sudo ip link set can0 type can bitrate 1000000 dbitrate 5000000 fd on \
     sample-point 0.8 dsample-point 0.75 berr-reporting on
sudo ip link set can0 txqueuelen 1000
sudo ip link set up can0
candump -x can0     # -x shows the extra flags such as BRS and ESI

import can, struct, time

bus = can.Bus(interface="socketcan", channel="can0", fd=True)

def cyclic_command(joint_id, position_counts, torque_limit):
    # Illustrative 8-byte RPDO-style payload: controlword, target pos, torque limit
    payload = struct.pack("<HiH", 0x000F, position_counts, torque_limit)
    return can.Message(arbitration_id=0x200 + joint_id, data=payload,
                       is_extended_id=False, is_fd=True, bitrate_switch=True)

t0 = time.monotonic()
for tick in range(1000):
    for j in range(1, 13):
        bus.send(cyclic_command(j, tick * 10, 500))
    time.sleep(max(0.0, t0 + (tick + 1) * 0.001 - time.monotonic()))

This sketch is a Python demonstration; time.sleep pacing on a general-purpose Linux kernel jitters by tens to hundreds of microseconds, which is fine for a bench test and not for a production 1 kHz loop. Use a PREEMPT_RT kernel, a pinned real-time thread and a C or C++ control loop in production, and let the CAN controller’s own transmit queue (and, where available, hardware timestamping) enforce the schedule. The identifier 0x200 plus the node ID follows the CANopen predefined connection set for RPDO1, but the payload packing is illustrative and does not reproduce a specific drive’s PDO mapping.

Trade-offs, Gotchas, and What Goes Wrong

Mixed-node buses fail loudly. A single Classical-CAN-only node on a CAN FD bus will raise error frames on every FD frame, and error-passive and bus-off logic will then misbehave on the nodes that are correct. Either remove legacy nodes, use FD-tolerant controllers in their passive mode, or segment with a gateway. The same applies to CAN XL: XL frames are recognised only by XL-capable controllers, and I did not verify the exact tolerance behaviour of FD-only nodes towards XL frames, so read ISO 11898-1:2024 and CiA 610 before planning a mixed bus.

Arbitration is a feature you may not want. Priority arbitration is excellent for a mixed-criticality bus. In a joint bus where all frames have roughly equal urgency, it means a lower-ID joint always beats a higher-ID joint, producing a fixed jitter pattern: the last joint in the priority order sees the full cycle’s worth of preceding traffic as latency. Time-triggered CAN schedules, or SYNC-driven PDO phasing, are the standard mitigations.

Bit rate is not throughput. The load table above shows that at small payloads the nominal-rate header dominates, so a 5 Mbit/s data phase buys only a 2.3x frame-time improvement over Classical CAN at 8 bytes (111 us versus 48 us), not 5x. Payload packing gives the real gain.

Bit timing is the usual root cause. Sample point placement, synchronisation jump width and oscillator tolerance cause most field failures that look like “random bus-off”. For CAN FD both the nominal and the data phase need their own timing, and the data-phase sample point is typically earlier than the 80 percent used in Classical CAN. Use a CAN-capable oscilloscope or analyzer and look at the eye diagram of the data phase, not only the decoded frames.

CANopen FD and CAN XL maturity. CiA 1301 and CiA 610 exist, but drive-profile coverage, off-the-shelf servo drives and test tools lag Classical CANopen by years. Count your suppliers: if the drive you want does not speak CiA 1301, the theoretical benefit of CANopen FD is zero.

Security. CAN has no authentication. CANsec for CAN XL (CiA 613-2) was listed by CiA as under development on the page I read, so do not design a threat model around it yet. For robots with remote connectivity, put a gateway with filtering between any external interface and the joint bus.

Cost of EtherCAT is not only silicon. A line topology makes cable failure a segment-wide failure unless you add a ring with redundancy, and Ethernet PHYs and magnetics consume more board area and power per node than a CAN transceiver. Count it per joint: for small actuators, a CAN transceiver and a controller on the same microcontroller is a real advantage.

Practical Recommendations

For a new robot with fewer than about six joints and a 1 kHz loop, CAN FD at 1 Mbit/s nominal and 5 Mbit/s data with 8 to 16-byte PDOs is comfortable. For 6 to 16 joints, either pack payloads, move to 2 Mbit/s nominal with SIC transceivers on a short trunk, or split into two buses. Above that, or when loop times fall under 500 microseconds, pick EtherCAT with CoE and CiA 402 and keep CAN for peripherals such as grippers, battery management and tool changers.

Choose CANopen (CiA 301 with CiA 402) when you need third-party servo drives and standard tools; choose CANopen FD where the ecosystem supports it and you need 64-byte PDOs or USDO routing; choose a custom CAN FD protocol only for a closed system where you control all nodes. Choose CAN XL when your payloads are genuinely large (firmware, sensor tiles, tunnelled Ethernet) and your silicon vendor can show shipping controllers and SIC XL transceivers; do not choose it only because the bit rate is larger.

Checklist before freezing the design:

• Compute bus load from bit counts for nominal and worst-case stuffing, including SYNC, heartbeat and SDO traffic; target under 50 percent at the control rate.
• Specify SIC transceivers if any stub exceeds a few centimetres at data rates above 2 Mbit/s.
• Verify every node is FD-capable or FD-tolerant before enabling BRS.
• Fix the topology: trunk, two 120 ohm terminators, short stubs, no unterminated stars.
• Define bus-off recovery behaviour and heartbeat supervision with the safety controller.
• Confirm drive-profile support (CiA 402, CiA 1301) in each supplier’s datasheet, not marketing material.
• Keep one object model (CiA 402) so the transport can change later without rewriting application code.

If your CAN segment feeds an edge gateway and a unified namespace, the practical patterns are in our guide to brownfield Modbus retrofit to a unified namespace; the same gateway design applies when the source protocol is CANopen.

Frequently Asked Questions

What is the difference between CAN FD and CAN XL?

CAN FD (ISO 11898-1:2015) carries up to 64 data bytes and switches to a faster data phase after arbitration, commonly in the 2 to 8 Mbit/s range. CAN XL (ISO 11898-1:2024) carries 1 to 2048 bytes, separates an 11-bit priority ID from a 32-bit acceptance field, adds SDT, VCID and SEC fields, and uses a push-pull fast phase with PWM coding for 20 Mbit/s and beyond on SIC XL transceivers. Both keep priority arbitration at the nominal rate.

Is CANopen a replacement for CAN FD?

No. CANopen is an application layer; CAN FD is a data-link layer. CiA 301 CANopen runs on Classical CAN, and CANopen FD (CiA 1301) runs on CAN FD. Choosing CANopen gives you an object dictionary, PDO and SDO services, NMT and device profiles such as CiA 402, while choosing CAN FD only gives you the frame format. Many CAN FD systems use a proprietary or J1939-style layer instead.

How fast is the CAN FD bit rate in practice?

The arbitration phase is normally 500 kbit/s or 1 Mbit/s, and the data phase is commonly 2 to 5 Mbit/s with conventional transceivers, up to 8 Mbit/s with SIC transceivers on suitable topologies. Texas Instruments notes that real vehicle networks often limit regular transceivers rated for 5 Mbit/s to under 2 Mbit/s because of ringing. The achievable rate depends on stubs, termination, cable length and sample-point settings, not on the controller.

Can CAN XL replace EtherCAT for robot joints?

On the evidence I could verify, no. CAN XL targets larger payloads and Ethernet-style tunnelling, not tight multi-axis synchronisation. EtherCAT moves all joints in one frame with distributed clocks, and keeps CiA 402 through CoE. CAN XL could suit a gateway or sensor segment carrying large payloads, but I found no published joint-controller benchmarks or mature drive ecosystem to justify replacing EtherCAT in servo systems.

Do I need SIC transceivers for CAN FD?

Not always. A short, properly terminated linear bus at 2 Mbit/s often works with regular CAN FD transceivers. SIC (CiA 601-4, integrated into ISO 11898-2:2024) matters when you have stubs or star branches and want data rates of 5 Mbit/s or higher, because it actively suppresses the ringing after the dominant-to-recessive edge. SIC transceivers can share a bus with regular CAN FD nodes, so they can be introduced incrementally.

Which bus do humanoid robots use for joints?

There is no single answer and I could not verify a specific public architecture for any named humanoid. Practical designs use CAN or CAN FD for small actuators with moderate loop rates, and EtherCAT for dense, high-rate joint chains, often combined with a gateway at the limb or torso. Select by bus-load arithmetic like the example above, not by what another product reportedly uses.

Further Reading

• PROFINET vs EtherCAT vs OPC UA FX over TSN: deterministic Ethernet in 2026
• PROFINET, EtherCAT and OPC UA FX compared
• IEC/IEEE 60802 TSN profile for industrial automation
• ros2_control hardware interface tutorial
• Brownfield Modbus retrofit to a unified namespace
• External: CAN in Automation, CAN XL; CiA, CANopen FD faster and with improved functionality; Texas Instruments, CAN SIC application note SLLA581

By Riju — about