For decades, CAN has been one of the most dependable languages used by machines. Controllers, sensors, actuators, operator panels and safety modules can exchange information with predictable priority and the robustness required by industrial and automotive environments. Today, however, a machine is no longer sending only a few commands and states: it has to handle richer diagnostics, high-frequency feedback, more capable HMIs, updates, data from multiple sensors and distributed software components.
In this context, CAN XL is not simply faster CAN. It is the third generation of the CAN protocol, designed to increase the amount of data a network can carry without giving up the principles that made CAN so widespread in control systems.
The subject has become especially timely after Texas Instruments announced the TCAN6062, described as the first commercially available CAN XL transceiver, on August 12, 2026. It moves CAN XL from standardisation into the practical availability of hardware for industrial products, robots, HMI systems and next-generation control architectures.
For a team building a machine, an embedded device or a product with several electronic nodes, the question is not “should we replace CAN?” A more useful question is: will our communication architecture still be adequate when data, software functions, sensors and diagnostic requirements grow?
At a glance
- CAN XL is the third generation of the CAN protocol and is standardised in the ISO 11898:2024 family.
- It supports data fields up to 2,048 bytes and configurable data rates up to 20 Mbit/s, depending on the physical network design.
- TI's first commercial CAN XL transceiver makes the technology practical to evaluate for new industrial products.
- It is not an automatic replacement for CAN FD or Ethernet: it is relevant when a product needs more data while retaining priority, determinism and continuity with the CAN world.
From classic CAN to CAN XL: the evolution is about more than speed
Classic CAN was created for control networks in which short, high-priority messages must arrive reliably. CAN FD has already extended that model by increasing the data field and making it easier to support richer firmware, diagnostics and extra functions.
CAN XL takes a further step. According to CAN in Automation, the international association behind the CAN ecosystem, the protocol can use data fields of up to 2,048 bytes and configurable throughput up to 20 Mbit/s. The association identifies CAN XL as the third CAN generation, alongside classic CAN and CAN FD, in ISO 11898-1:2024.
| Technology | Typical role | Data-field limit |
|---|---|---|
| Classic CAN | Commands, status and essential control signals. | 8 bytes per frame. |
| CAN FD | Networks with more diagnostics, application data and a need for greater efficiency. | 64 bytes per frame. |
| CAN XL | Architectures with larger data flows, robotics, advanced HMIs and integration with IP networks. | Up to 2,048 bytes per frame. |
The difference has an important practical effect. When information has to be fragmented across many CAN FD messages, it does not only take longer to transmit: bus load rises, firmware becomes more complex, there are more cases to verify and predictable response times are harder to preserve under load.
CAN XL lets engineers work with larger packets while retaining CAN arbitration. Important messages can still receive priority, while the network has more room for diagnostics, parameters, sensor data and updates.
Why robots, HMIs and industrial machines are creating a new network problem
A modern industrial machine is no longer a linear chain in which a PLC sends one command and an actuator returns one state. It is increasingly a distributed system: drives, I/O modules, HMI panels, safety controllers, gateways, cameras, smart sensors and support software must coexist without turning the network into a bottleneck.
In industrial robots, for example, motion control requires priority and predictable timing. At the same time, the system may need to collect encoder data, torque-sensor measurements, temperatures, drive diagnostics and information useful for maintenance. In HMIs, the amount of configuration, recipes, service logs, process parameters and operator-facing information also keeps increasing.
The need is not created by artificial intelligence or cloud connectivity alone. Even when every data point stays on-site, edge computing brings more processing close to the machine. Local nodes then need to exchange richer information while preserving a reliable control foundation that can be understood and supported throughout the product lifecycle.
Texas Instruments specifically cites humanoid robots, industrial robots and HMI systems among the intended applications for its new transceiver. The value of that announcement is therefore not limited to a single component: it signals that higher-capacity CAN architectures are becoming a concrete option beyond a purely theoretical protocol discussion.
Why the first commercial hardware changes the time to evaluate CAN XL
CAN XL did not start in August 2026. Its protocol and physical layer were already standardised. What changes is that a commercial transceiver makes it possible to build a real evaluation chain: compatible controller, transceiver, network topology, firmware, test tools and prototype.
The TCAN6062 supports the CAN XL physical-layer requirements of ISO 11898-2:2024. Its data sheet also describes modes intended to reduce ringing in complex topologies and to handle the fast data phase. This does not remove network-design work. On the contrary, it confirms that at higher speeds, wiring, termination, stub length and signal quality are part of the product design rather than details to fix at the end.
One misconception is worth avoiding: changing the transceiver does not automatically turn an existing machine into a CAN XL system. The controller must support the protocol, firmware must manage the new stack, the network must be verified physically and the behaviour of existing nodes must be designed carefully. TI states that the component supports CAN FD and CAN SIC operation in mixed networks, but the actual migration path depends on the product architecture, not on replacing a single chip.
CAN XL does not automatically replace Ethernet
When data volumes grow, Ethernet is often the first answer. In many applications that is the right choice: Ethernet remains appropriate for large streams, complete IP networks, cameras, industrial PCs, gateways and enterprise infrastructure.
CAN XL addresses a different problem. It retains CAN's non-destructive arbitration, which makes it possible to give priority to messages that cannot wait. It can be attractive when control, sensors and diagnostics must share an architecture without imposing the complexity of a complete Ethernet network on every node.
The two technologies can also coexist. CAN in Automation describes mapping Ethernet frames into CAN XL frames, while Texas Instruments refers to TCP/IP tunnelling in mixed architectures. That does not make Ethernet unnecessary. It means a product can use Ethernet where broad connectivity is required and CAN XL where priority, distributed control and continuity with an existing CAN estate matter more.
The right decision is not “CAN XL or Ethernet?” but “which data must move, which data has priority, which nodes must remain simple, and which architecture can be maintained after delivery?”
When CAN XL is worth evaluating in a new product
CAN XL is not necessary on every microcontroller board. A simple sensor, a low-frequency actuator or a machine with a small number of short messages can continue to work extremely well with classic CAN or CAN FD.
The question becomes relevant when a team is already encountering concrete limits: bus load is high; diagnostics are reduced so control is not slowed; useful data travels over a poorly integrated second network; or the HMI needs an increasing amount of information from peripheral modules.
| Question to ask | Why it matters |
|---|---|
| Are CAN FD messages being fragmented continuously? | Fragmentation increases overhead, application complexity and the number of test cases. |
| Must control share a network with richer diagnostics and sensor data? | Critical messages need priority without losing system visibility. |
| Will the product grow with new modules, HMIs or software functions? | A network sized only for the prototype can become a limit during industrialisation. |
| Are there CAN FD nodes that must be retained? | Migration can be gradual, but it has to be planned at architecture level. |
The decision should not be based on a protocol's headline peak rate. A network designed for 20 Mbit/s does not automatically deliver 20 Mbit/s in every topology. The result depends on the physical characteristics of the machine: number of nodes, cable lengths, branches, connectors, electromagnetic interference, power and environmental conditions.
This is where a proof of concept is more valuable than a catalogue choice. Before a final PCB is defined, a team can simulate load, analyse expected traffic, build a representative network and measure latency, errors, degraded behaviour and diagnostic capability.
Migration is not a bus update: it is an architectural decision
In an existing product, moving toward CAN XL requires hardware, firmware and support processes to be considered together. The first step is not choosing a component. It is understanding what crosses the network today, how often it does so, which information is genuinely essential and where bottlenecks are emerging.
The options can then be compared. In some cases, optimising the application protocol is enough. In others, keeping CAN FD for control and adding Ethernet for one specific function is a better fit. CAN XL becomes particularly interesting when the aim is to reduce fragmentation, create room for growth and retain CAN's priority model in a more capable network.
existing architecture → measured real traffic → future requirements → topology → prototype → firmware and physical-layer verification → industrialisable decision
This approach avoids two opposite mistakes. One is adopting a new technology simply because it is available, without a measurable benefit. The other is retaining a saturated network because it “has always worked”, only to find the limit when the product needs a new HMI, gateway, support function or sensor-rich module.
Example: a modular machine with HMI, drives and diagnostics
Consider a modular machine with multiple axes, an operator panel, acquisition modules and a service gateway. CAN FD sends commands and states. Over time, the company adds process parameters, drive diagnostics, recipes, quality data and predictive-maintenance requirements.
Each new feature appears small at first. The result, however, is that information is split across many messages, diagnostics are limited during busy phases and firmware must coordinate a growing number of communication channels. CAN FD is not “wrong”; the original architecture was simply not sized for the product's real evolution.
A CAN XL assessment can determine whether diagnostic and configuration flows can move more efficiently while preserving priority control messages. It can also clarify whether a combined CAN XL and Ethernet design correctly separates local control, HMI functions and gateway connectivity.
The useful outcome is not the promise of a “more modern” network. It is an architecture that identifies which nodes to update, which to retain, which data to move, which physical constraints to respect and how to verify system stability before production.
Frequently asked questions about CAN XL
Can CAN XL already be used in commercial products?
The protocol and physical layer are standardised in the ISO 11898:2024 family. TI's TCAN6062 announcement provides a commercial component with which to start evaluations and new projects. A complete system still depends on controller availability, tools, firmware and the product's requirements.
Does CAN XL replace CAN FD?
No. CAN FD remains an excellent solution for many embedded networks. CAN XL should be considered when larger frames, throughput and architectural growth create a measurable benefit over the complexity of migration.
Can any microcontroller become CAN XL-capable with a new transceiver?
No. A transceiver implements the physical layer; the controller and firmware must support CAN XL. Feasibility must therefore be checked against the specific MCU, any real-time operating system in use and the available software stack.
Is CAN XL only an automotive technology?
No. CAN has strong automotive roots, but the newly available hardware is also presented for industrial robots, HMIs and control systems. The assessment should start with the use case, not with the sector in which the protocol originated.
Can CAN XL replace Ethernet in a machine?
Not universally. Ethernet can remain essential for high-capacity links, industrial PCs, gateways, cameras and IP networks. CAN XL is useful when a team wants to retain CAN priority behaviour while increasing the capacity of a distributed control network.
How Silicon Logix can support an evaluation
Silicon Logix can support companies and technical teams in evaluating the communication architecture of machines, embedded devices and modular systems. The work can begin with an existing CAN or CAN FD network, a new product under definition or a prototype that must progress toward industrialisation.
The objective is not to recommend CAN XL by default. It starts with data flows, priorities, topology, available MCUs, firmware and the future needs of the HMI, diagnostics, gateway or remote support. From there, the team can define a measurable proof of concept and a realistic technical path for the product.
Where needed, the assessment can continue with embedded firmware development, protocol integration, HMI interfaces, Linux gateways or diagnostic tools. The goal is to keep the device, communications and support software coherent without adding needless complexity.
Conclusion
The first commercially available CAN XL transceiver marks an important transition: a technology already defined by standards is becoming a concrete choice for teams designing the next generation of industrial products.
CAN XL will not erase classic CAN, CAN FD or Ethernet. Each technology will retain its place. Its value lies in an increasingly important space: networks that must carry more data without giving up priority, robustness and continuity with the CAN ecosystem.
For a company, the best decision is not adopting the newest protocol. It is designing a network with room for the product's actual evolution, one that can be verified before production and remains maintainable when the machine, firmware and customer requirements change.
The question is no longer only:
“How much data can we transmit today?”
It becomes:
“Will our architecture handle the next HMI, the next module and the next functions without having to be redesigned from scratch?”
Official references
- Texas Instruments, TI advances next-generation industrial systems with the first commercially available CAN XL transceiver, August 12, 2026.
- Texas Instruments, TCAN6062 CAN XL Transceiver with Standby Mode data sheet, ISO 11898-2:2024 physical requirements and component characteristics.
- CAN in Automation, CAN XL, official description of the third CAN generation, payload and throughput.
- CAN in Automation, CAN XL (extended data-field length), XL frame structure and its relationship to classic CAN and CAN FD.
- CAN in Automation, ISO 11898-1:2024 released, standardisation of classic CAN, CAN FD and CAN XL.
- CAN in Automation, Physical layer options, CAN SIC XL physical-layer characteristics and network-design constraints.
Are you designing a machine, HMI or device with more nodes and more data to manage?
Silicon Logix can carry out a technical assessment of the communication architecture, analysing traffic, priorities, nodes, firmware, topology and the product's room to evolve.
The work can start from an existing CAN or CAN FD network or from a new project, with a focused proof of concept before the hardware design is finalised.
Request a technical assessment of your project
Canonical source: CAN XL: what changes for robots, HMIs and industrial machines.
