The first CAN XL transceiver arrives two years after the standard, from one supplier

Run the arithmetic before deciding what the part is for. A 2,048-byte data field is 16,384 bits, and at the 20 Mbit/s ceiling that CAN in Automation quotes, that clears in roughly 0.82 ms of data-phase time ^[1][3]. Protocol overhead, the arbitration phase and whatever rate the harness actually tolerates all make it worse, so read it as a floor rather than a spec line. It is still the number that decides things, because the comparison is not against Ethernet. It is against the same payload chopped into CAN FD frames with a reassembly layer underneath.

That layer is where the money sits. The dev.to write-up is specific about what fragmentation does: bus load climbs, firmware gets more complex, the number of cases to verify grows, and predictable response times become harder to hold under load ^[6]. None of that appears as a line item on a bill of materials. It appears as rows in a test matrix, and as the engineer who owns a reassembly state machine for as long as the machine is supported in the field.

There is a second reason this lands in the current design cycle rather than the next one. CAN XL has carried an ISO 11898-1:2024 designation and third-generation status on paper since 2024 ^[2]; the transceiver turned up in August 2026, about two years behind it ^[2]. A team that read the standard when it was published and shelved it was making the right call about silicon that did not exist yet. Per the same coverage, that call now has exactly one answer available: "first commercially available" means one supplier on the day it was said ^[1].

Worth being precise about who asserts what here. The 2,048-byte and 20 Mbit/s figures are attributed to CAN in Automation, the association behind the CAN ecosystem, and both are qualified as depending on the physical network design ^[3]. The application list, humanoid robots, industrial robots and HMI systems, is Texas Instruments describing its own target market ^[5]. The judgement that CAN XL is not an automatic swap for CAN FD or Ethernet, and matters only where a product needs more data while keeping priority and determinism, belongs to the dev.to author ^[7].

The migration argument that survives all that qualification is the boring one. CAN XL keeps CAN arbitration, so high-priority messages still win the bus and the scheduling assumptions in existing control code do not have to be rewritten to gain headroom ^[4]. CAN FD already ran this play once by enlarging the data field ^[8], which means most teams facing the question have already built the fragmentation code they would be retiring, and know precisely what it cost.

For plenty of machines the honest answer stays CAN FD plus a splitter that already works and is already validated. What changed on 12 August 2026 is that keeping it became a decision with a part number on the other side, rather than the only thing on offer.