---
title: "Choosing between CAN, CAN FD and Ethernet industrial links"
tldr: "CAN suits cheap, rugged, low-rate event traffic; CAN FD when payloads outgrew 8 bytes but a bus still fits; industrial Ethernet (PROFINET, EtherCAT, TSN) for megabits or tight cycle times. Expect to bridge, not replace."
type: "reference"
hub: "Industrial Connectivity & Gateways"
published: "2026-09-03"
updated: "2026-09-03"
canonical: "https://exubits.com/engineering/can-canfd-ethernet-industrial-links"
author: "Exubits Engineering"
---

# Choosing between CAN, CAN FD and Ethernet industrial links

> CAN suits cheap, rugged, low-rate event traffic; CAN FD when payloads outgrew 8 bytes but a bus still fits; industrial Ethernet (PROFINET, EtherCAT, TSN) for megabits or tight cycle times. Expect to bridge, not replace.

This decision gets made badly in two directions. Teams keep classic CAN because
"it has always worked" and then spend a year fighting bus-load and 8-byte frames.
Or they jump to industrial Ethernet everywhere and discover it costs more per
node, needs managed switches, and still does not give them determinism unless
they configured it for it.

Here is how the three actually differ, and what each is bad at.

## Classic CAN (ISO 11898-1/-2)

**What it is**: a multi-drop differential bus, up to 1 Mbit/s, 8 data bytes per
frame, non-destructive bitwise arbitration by identifier, strong error detection
(15-bit CRC, bit monitoring, form/stuff checks) with automatic retransmission.

**What it is genuinely good at**:

- **Cost and ruggedness.** A CAN transceiver is cents. The bus is two wires, no
  switch, no hub, tolerant of ground shift and EMI, and it degrades gracefully —
  a node dropping off does not take the segment down.
- **Event-driven traffic with priority.** Arbitration means the lowest-numbered
  ID always wins the bus with no collisions and no configuration. For "report
  this alarm now" traffic that is exactly right.
- **Determinism at low load.** Below roughly 30–40% bus load, worst-case latency
  for a given priority is calculable and small.
- **Ecosystem.** CANopen, J1939, and decades of tooling, diagnostics, and
  engineers who know it.

**What it is bad at** — state these before choosing it:

- **8 bytes.** A 12-axis sensor packet or any structured record needs
  fragmentation (ISO-TP), which adds latency, state, and failure modes.
- **1 Mbit/s ceiling**, and you only reach it on a short bus. At 1 Mbit/s the
  practical bus length is on the order of 40 m; longer buses force lower rates
  because arbitration needs the signal to propagate to the far end within a bit.
- **Bus load cliff.** Above ~50–60% load, low-priority frames see large and
  hard-to-bound latency, and a chatty node can starve them entirely.
- **No native security.** No authentication, no encryption; any node can send any
  ID. Mitigations exist (bus guardians, MACsec-style add-ons, segmentation) but
  they are bolt-ons.
- **A single retransmitting faulty node** can dominate the bus until error
  confinement kicks in.

## CAN FD (ISO 11898-1:2015)

**What it changes**: up to **64 data bytes** per frame, and a **second, faster
bit rate** for the data phase (commonly 2–5 Mbit/s, 8 Mbit/s achievable with
care) while the arbitration phase stays at the classic rate. Better CRC (17- or
21-bit) for the larger payload.

**Why it is often the right upgrade**:

- **The 8-byte problem disappears** without fragmentation. One 64-byte frame
  instead of eight classic frames means less protocol overhead and less software
  state.
- **Effective throughput rises several-fold** for payload-heavy traffic, because
  both the payload is bigger and the data phase is faster.
- **You keep the topology, the transceivers' ruggedness, the arbitration model,
  and most of the tooling.** It is an incremental change, not a re-architecture.
- CANopen FD and J1939 variants exist to carry the ecosystem forward.

**What it is bad at / what to watch**:

- **The arbitration phase is still limited to the classic bit rate.** CAN FD does
  not raise the number of *frames per second* you can arbitrate; it raises the
  bytes per frame. A system that is frame-rate-bound, not payload-bound, gets
  little from it.
- **Signal integrity gets harder.** The fast data phase shrinks bit times to
  hundreds of nanoseconds; ringing, stub length, connector quality, and
  transceiver loop delay now matter. A messy bus that tolerated 500 kbit/s
  classic will not tolerate 5 Mbit/s FD without topology work and possibly ring
  or point-to-point rather than long stubs.
- **Mixed classic/FD segments need care.** A classic-only node on an FD bus sees
  FD frames as errors and floods the bus unless partial networking / FD-tolerant
  transceivers are used. Usually the whole segment must be FD.
- **Controller support**: older MCUs have classic-only CAN peripherals. Check the
  silicon, not the datasheet marketing.

## Switched industrial Ethernet — PROFINET, EtherCAT, and TSN

Not one thing. "Industrial Ethernet" covers protocols with very different
determinism stories, all on 100 Mbit/s or 1 Gbit/s PHYs.

- **PROFINET RT** — standard switched Ethernet, prioritised frames, cycle times
  down to ~1 ms; **PROFINET IRT** adds hardware time-slotting for sub-millisecond,
  low-jitter cycles but needs IRT-capable switches.
- **EtherCAT** — a single frame passes through every node, each reading and
  writing its slice on the fly ("processing on the fly"). Extremely efficient,
  cycle times to tens of microseconds, but it is a specific master/slave topology
  with EtherCAT slave controllers in each node, not general IP networking.
- **TSN** (IEEE 802.1 set — 802.1AS, Qbv, Qci, CB, …) — brings scheduled,
  bounded-latency traffic to *standard* Ethernet, letting control traffic and IT
  traffic share the same infrastructure. It is the direction the industry is
  moving; it also requires TSN-capable switches and endpoints and non-trivial
  network engineering (a schedule computed and pushed to every bridge).

**What Ethernet buys you**:

- **Bandwidth**: 100–1000 Mbit/s, so video, firmware images, and high-channel-
  count data are no longer a problem.
- **Routable, IT-integratable**: TCP/IP, TLS, MQTT/OPC UA to the cloud on the
  same wire (with segmentation and a firewall).
- **Determinism *if configured for it***: IRT, EtherCAT, or TSN give bounded
  latency and low jitter — but plain "Ethernet" does not; a standard switch under
  load has queueing delay and no guarantees.

**What it is bad at**:

- **Cost and complexity per node**: a PHY, magnetics or connector, often a
  managed or special switch, more powerful MCU/SoC, and a stack. Multiples of a
  CAN node.
- **Topology and cabling**: star or line with switches, 100 m segment limit per
  hop, more connectors, more to go wrong mechanically in a vibrating machine.
- **Determinism is opt-in and fragile to misconfiguration.** A well-meaning IT
  change, a non-TSN device plugged into a TSN segment, or an unmanaged switch
  dropped in "temporarily" can quietly break the timing guarantees.
- **Security surface**: now you are on an IP network, with everything that
  implies. IEC 62443 becomes your problem.

## A decision order that works

1. **What is the largest single payload, and how often?** ≤ 8 bytes, event-rate
  → classic CAN is still fine. 8–64 bytes → CAN FD. Kilobytes, or any streaming
  → Ethernet.
2. **What is the tightest cycle time with bounded jitter you must hit?**
  Above 5–10 ms and modest, CAN/CAN FD or PROFINET RT. Around 1 ms, PROFINET IRT
  or CAN FD on a lightly loaded bus. Under 250 µs with many axes, EtherCAT. Mixed
  critical and best-effort on one wire, TSN.
3. **Node count, cost target, and environment.** Dozens of cheap rugged nodes on
  a harness → bus wins. A cell with a handful of high-value devices and a video
  feed → Ethernet.
4. **Does it need to talk to IT / cloud directly?** Yes and at rate → Ethernet.
  Occasionally → keep the fieldbus and put the IP stack in the gateway.
5. **Who maintains it for ten years?** A plant electrician can fault-find a CAN
  bus with a multimeter. A TSN schedule needs someone who understands 802.1Qbv.

## The realistic answer is usually "bridge"

Greenfield-everything-Ethernet is rare. The common shape is CAN or CAN FD at the
machine edge for sensors and drives, aggregated by a **gateway** that speaks the
fieldbus on one side and OPC UA / MQTT over Ethernet on the other, doing protocol
translation, buffering across link outages, and store-and-forward. That gateway is
also the right place to put the security boundary, the data-model mapping, and the
firmware-update path — rather than pushing all of that cost into every edge node.

Designing that seam well — which data is published at what rate, what is buffered,
how backpressure and reconnection behave — is usually more of the engineering
effort than picking the physical layer.