Industrial CAN reference · Primary-source review 25 July 2026
CAN Bus Protocol: Frames, Arbitration & PLC Integration
CAN bus is a multi-master, broadcast serial network standardized in ISO 11898. Every node sees each frame; the identifier describes the message and sets arbitration priority. CAN supplies framing, error detection, retransmission, and fault confinement, but a higher-layer protocol must define what the data means.
That distinction matters in a PLC project: a controller with a raw CAN port is not automatically a CANopen, DeviceNet, or SAE J1939 controller. Confirm the exact stack at both ends before selecting hardware or writing the I/O map. [1] [2]
- Classical payload
- 0–8 bytes
- CAN FD payload
- 0–64 bytes
- Identifier formats
- 11 or 29 bit
- Universal node limit
- None
Evidence boundary
What this guide means by “CAN bus”
This page focuses on Classical CAN and CAN FD in industrial PLC integration. ISO 11898-1 defines the data link layer and physical coding sublayer; a physical-medium implementation such as high-speed differential CAN is a separate design choice. Cable length, node count, cycle time, and usable data-phase rate depend on transceivers, topology, bit timing, loading, and the selected higher-layer protocol. They are not single CAN-wide guarantees.
CAN frames, arbitration, and errors
1. Data frame
A Classical CAN data frame contains start of frame, arbitration, control, a 0-to-8-byte data field, CRC, acknowledgement, and end of frame. Base format uses an 11-bit identifier; extended format uses 29 bits. CAN FD keeps 11-bit and 29-bit formats, raises the payload ceiling to 64 bytes, and can switch to a faster bit rate for the data phase. The arbitration phase still runs at the nominal bit rate. [4]
2. Non-destructive arbitration
A transmitting node also monitors the bus. Dominant bits overwrite recessive bits; a node that sends recessive but reads dominant stops transmitting and retries later. At the first differing identifier bit, the dominant value wins, so a lower numerical identifier generally has higher priority. Arbitration does not corrupt the winning frame, but sustained high-priority traffic can delay lower-priority messages.
0x080 → wins access first
0x200 → detects dominant bit, stops, retries
3. Detection, retransmission, and fault confinement
CAN controllers check bit, stuff, CRC, form, and acknowledgement conditions. When a node detects an error, an error frame aborts the current transfer and the sender normally retries. Transmit and receive error counters move a controller between error-active, error-passive, and bus-off states so a persistently faulty node cannot disturb the bus indefinitely. [2]
An ACK only confirms that at least one receiver accepted the frame at the CAN layer. It does not prove that the intended PLC task consumed the correct engineering value.
CAN vs CANopen, DeviceNet, and J1939
These names are not interchangeable. The same physical transceiver does not create application-layer compatibility.
| Technology | What it defines | PLC integration consequence |
|---|---|---|
| Raw CAN | Frames, identifiers, arbitration, acknowledgement, error signaling, and fault confinement. The payload meaning is application-specific. | You must define every ID, format, byte order, scaling, update period, timeout, and recovery rule. |
| CANopen | CiA 301 application and communication profile, including the object dictionary and SDO, PDO, NMT, and error-control services; device profiles add standardized behavior. [5] | Select a CANopen-capable controller, module, or gateway and match EDS/profile, node ID, PDO mapping, and NMT behavior. |
| DeviceNet | ODVA's adaptation of CIP to CAN, with DeviceNet transport and physical-layer conventions, device power, and explicit and I/O messaging. [6] | Use a DeviceNet scanner/interface and the vendor's EDS and connection model. A generic CAN channel is not a substitute. |
| SAE J1939 | A vehicle-oriented protocol family for on-road, off-road, and suitable stationary applications. J1939/21 uses Classical CAN extended frames with 29-bit identifiers. [7] | Confirm J1939 support, parameter-group mapping, addressing, transport handling, and the exact J1939 document set required by the equipment. |
Practical PLC integration workflow
- 1
Identify the application layer
Read the endpoint manual and record whether it exposes raw CAN, CANopen, DeviceNet, J1939, or a proprietary CAN profile. Do not infer the stack from the connector or transceiver.
- 2
Prove the interface path
Confirm that the exact PLC CPU, communication module, or gateway supports that stack, identifier format, nominal bit rate, and—if required—CAN FD. Check current firmware and configuration-tool compatibility.
- 3
Write the message contract
For each value, record the CAN ID or protocol object, producer, direction, length, byte order, signedness, scaling, valid range, update period, timeout, startup default, quality indication, and safe response to stale data.
- 4
Engineer the physical bus
For high-speed CAN, start from a line topology with 120-ohm termination at both ends, keep stubs within the equipment guidance, and apply the cable, shield, bonding, isolation, and common-mode rules from the transceiver and device manuals.
- 5
Build PLC diagnostics before process logic
Expose communication healthy, last-update age, timeout, invalid-range, module state, error count, and recovery status. Gate commands with explicit validity rather than treating a last-known value as live forever.
- 6
Bench-capture and reconcile
Capture identifiers, frame formats, payloads, periods, arbitration delays, and errors with an appropriate CAN interface or analyzer. Reconcile the capture against the written contract before energizing machine outputs.
- 7
Run failure acceptance tests
With outputs made safe, test cold start, network startup order, node loss, stale input, bus overload, bus-off, reconnection, PLC restart, gateway restart, and restoration of valid control.
The 120-ohm end-termination recommendation above applies to the usual high-speed CAN line topology; always defer to the selected physical-layer and equipment documentation. [3]
CAN bus troubleshooting and verification
| Symptom | Verify | Evidence to record | Decision |
|---|---|---|---|
| Entire bus silent | Module state, supply, CAN_H/CAN_L continuity, connector pinout, nominal bit rate, and termination. | Power-off resistance, scope trace, analyzer status, and controller diagnostic buffer. | Two 120-ohm end terminations commonly measure about 60 ohms in parallel with equipment powered off, but confirm the actual topology before treating that value as a pass/fail rule. |
| One node missing | Node power, unique address where applicable, receive filters, 11/29-bit format, and higher-layer state. | Raw capture, node LEDs, PLC module status, CANopen NMT or DeviceNet scanner diagnostics. | Separate “no frames from node” from “frames exist but the PLC stack rejects or does not map them.” |
| Intermittent error frames | End termination, stubs, cable damage, connector resistance, shielding/bonding, bit timing, and electrical noise. | Error counters over time, error-frame timestamps, bus voltage/waveform, machine-state correlation. | Correct the physical or timing cause; a cleared diagnostic counter alone is not evidence of repair. |
| Low-priority messages late | Bus load, message periods, identifier priorities, burst traffic, retransmissions, and worst-case response time. | Timestamped trace, load by interval, latency distribution, missed PLC deadlines. | Re-budget traffic and priority. Average bus load alone does not prove the worst-case deadline. |
| Analyzer decodes; PLC does not | Exact higher-layer protocol, ID format, payload length, byte order, scaling, EDS/profile, and gateway mapping. | One captured frame reconciled byte-for-byte to the device manual and PLC tag. | Fix the data contract or stack mismatch; physical-layer reception does not prove application compatibility. |
| Node enters bus-off | Which node's transmit counter rose first, error type, cabling/timing fault, and documented recovery behavior. | Counter trend, first-fault timestamp, controller log, and post-repair capture. | Remove the cause before recovery. Repeated automatic restart can hide a persistent wiring or configuration fault. |
CAN bus limitations and design cautions
- CAN does not define a universal application data model, device profile, engineering unit, or startup sequence.
- There is no protocol-wide maximum node count or cable length. Transceiver loading, topology, propagation delay, bit timing, and the higher-layer specification set the practical limits.
- Priority arbitration is predictable, but a “real-time” label is not a deadline proof. Traffic, errors, retries, and lower-priority starvation need analysis.
- Classical CAN carries no more than 8 payload bytes per data frame; larger application transfers require a higher-layer segmentation method or CAN FD.
- A Classical-only node is not transparently compatible with CAN FD traffic; mixed networks need an explicit compatibility design.
- Base CAN does not provide authentication, authorization, encryption, or freshness protection. Security and network segmentation have to be engineered above and around it.
- A shared connector, nominal bit rate, or successful ACK does not prove CANopen, DeviceNet, J1939, proprietary-profile, or byte-level interoperability.
- Simulation and packet capture can prove the modeled behavior only. Final acceptance still requires the real PLC module, transceivers, wiring, devices, firmware, and failure modes.
Primary sources
Standards and official technical references
Reviewed 25 July 2026. ISO publishes the standard scope online; the complete ISO text may require purchase. CiA, ODVA, and SAE are the responsible protocol or standards organizations for the linked higher-layer material.
- [1] ISO 11898-1:2024 — CAN data link layer and physical coding sublayer
- [2] CAN in Automation (CiA) — Classical CAN frames and error handling
- [3] CAN in Automation (CiA) — high-speed CAN transmission and termination
- [4] CAN in Automation (CiA) — CAN FD payload and bit-rate switching
- [5] CAN in Automation (CiA) — CANopen application layer and communication profile
- [6] ODVA — DeviceNet as CIP on CAN technology
- [7] SAE International — J1939/21 data link layer