Modern mobile machinery rarely relies on a single electronic device.
A typical control system may include:
Engine ECU
Sensors
Hydraulic control devices
Many of these devices communicate through CAN Bus.
Instead of running separate communication wiring between every device, multiple CAN nodes can share the same network.
However, connecting multiple CAN devices requires more than simply wiring CAN High and CAN Low together. Engineers must also consider network topology, termination, baud rate, communication protocols, and CAN channel allocation.
This article explains the basic principles for connecting multiple CAN devices to a mobile controller.
CAN is a multi-node communication network.
This means several devices can communicate over the same pair of CAN wires.
A simplified machine network may look like this:
120Ω 120Ω
│ │
└── Controller ── HMI ── Remote I/O ── Keypad ───┘
│
CAN Bus
Each device connected to the network is a CAN node.
Instead of requiring a dedicated communication line for every device, all nodes can transmit and receive CAN messages over the shared bus.
This is one reason CAN is widely used in mobile machinery.
A CAN network is normally designed around a main bus with devices connected along it.
The basic structure is:
120Ω 120Ω
│ │
════════ Main CAN Bus ═════════════════════
│ │ │
HMI Controller Remote I/O
Short branches, often called stubs, can connect devices to the main bus.
Long or poorly designed branches should be avoided because they can affect signal integrity, particularly as network speed and cable length increase.
A common mistake is creating an uncontrolled star network:
HMI
│
│
Remote I/O ─ Controller ─ Engine ECU
│
│
Keypad
Although some physical installations may appear similar to a star because of wiring-harness design, CAN electrical topology and branch lengths still need to follow appropriate network-design principles.
A CAN network normally uses 120 Ω termination resistors at both ends of the main bus.
120Ω 120Ω
│ │
└──── Controller ── HMI ── I/O ── ECU ────┘
Termination helps reduce signal reflections on the network.
A common installation error is adding termination to every device.
For example:
Controller → 120Ω
HMI → 120Ω
Remote I/O → 120Ω
ECU → 120Ω
This is generally not how a CAN bus should be terminated.
Only the two physical ends of the bus should normally provide termination.
Some devices have built-in or configurable termination, so engineers should check the documentation before wiring the network.
Devices communicating on the same CAN network must use the same CAN bit rate.
Common CAN bit rates include:
125 kbit/s
250 kbit/s
500 kbit/s
1 Mbit/s
For example:
Controller 250 kbit/s
HMI 250 kbit/s
Remote I/O 250 kbit/s
Keypad 250 kbit/s
These devices can potentially communicate on the same physical CAN network.
But if one device is configured for a different bit rate:
Controller 250 kbit/s
HMI 250 kbit/s
Remote I/O 500 kbit/s ← mismatch
communication with that device will fail and may disturb network operation.
Baud-rate configuration should therefore be one of the first items checked when commissioning a CAN system.
CAN defines the underlying communication mechanism, but higher-level protocols determine how CAN messages are organized and interpreted.
Mobile machinery may use:
SAE J1939
CANopen
Proprietary CAN protocols
Two devices having CAN interfaces does not automatically mean they can communicate with each other.
For example:
Engine ECU
↓
J1939
Remote I/O
↓
CANopen
Custom Device
↓
Proprietary CAN
The mobile controller must support or be programmed to handle the required protocol and message definitions.
This is an important consideration when integrating equipment from different suppliers.
Not every device needs to be placed on the same CAN network.
Controllers with multiple CAN interfaces allow engineers to separate communication networks.
For example:
Mobile Controller
/ | \
CAN 1 CAN 2 CAN 3
↓ ↓ ↓
Engine ECU HMI Remote I/O
J1939 + Keypad
Separating CAN networks can be useful when:
Devices use different protocols
Different baud rates are required
Network traffic needs to be separated
Machine subsystems need independent networks
Existing equipment already uses a dedicated CAN network
For example, an engine ECU may operate on a J1939 network while Remote I/O devices use another CAN channel.
The controller can then exchange information between different parts of the machine through its application logic.
A practical system might use the following architecture:
Engine ECU
│
J1939
│
CAN 1
│
Mobile Controller
/ \
CAN 2 CAN 3
│ │
HMI Remote I/O
│
CAN Keypad
The controller acts as the central control device.
It can:
Receive engine data through J1939
Process operator commands
Read Remote I/O data
Control hydraulic outputs
Exchange machine information with the HMI
Monitor communication status
This architecture can simplify integration while keeping different communication functions organized.
Every CAN message occupies network bandwidth.
As more devices and messages are added, CAN bus load increases.
For example, a network may contain:
Engine data
Joystick commands
HMI information
I/O status
Diagnostic messages
Hydraulic commands
If messages are transmitted too frequently, network traffic can become unnecessarily high.
Engineers should therefore consider:
Message transmission frequency
Number of CAN messages
Message priority
Required response time
Overall bus utilization
High-priority control data may require faster updates, while less critical information can often be transmitted less frequently.
A controller can also monitor whether expected messages continue to arrive.
For example:
Remote I/O
↓
CAN Message Every 100 ms
↓
Mobile Controller
If the controller stops receiving the expected message within a defined timeout period, it can identify a communication problem.
The control system may then:
Set a communication fault
Disable affected functions
Enter a fallback mode
Send a warning to the HMI
This is particularly important when a CAN device controls or monitors an important machine function.
Several issues frequently cause CAN communication problems in mobile machinery.
Too many, too few, or incorrectly positioned termination resistors can affect communication.
All nodes on the same physical CAN network must use a compatible bit rate.
Incorrect wiring can prevent communication.
Long branches can affect signal quality.
Two CAN devices may use completely different higher-level protocols.
Too many high-frequency messages can increase bus load.
A device may appear to have a CAN communication problem when the actual issue is its power supply or grounding.
Before commissioning a multi-device CAN network, engineers should verify:
CAN High and CAN Low wiring
Correct termination at both ends
Compatible baud rates
Appropriate bus topology
Reasonable stub lengths
Correct device power supply
Required CAN protocols
Message configuration
Device addresses or identifiers where applicable
CAN bus load
Communication timeout logic
A structured commissioning process can prevent many common CAN integration problems.
Connecting multiple CAN devices to a mobile controller can simplify the electrical architecture of modern mobile machinery.
HMI displays, engine ECUs, Remote I/O modules, keypads, and other devices can exchange information through shared CAN networks.
However, reliable communication depends on correct network design.
OEM engineers should consider:
Topology → Termination → Baud Rate → Protocol → CAN Channel → Bus Load → Diagnostics
For machines containing multiple CAN subsystems, a mobile controller with multiple CAN interfaces can help separate networks and integrate different devices into one coordinated control system.
English
