Setting Up a CANopen Network of Multiple SOLO Units

BLDC Speed Control using Arduino and CANopen

Introduction

A single CANopen bus can carry up to 127 device addresses, yet most multi-axis machines fail long before that number, often when the second drive joins the network. The jump from one axis to many changes how you think about the bus. A single drive forgives a lot. A network of drives does not.

This guide shows you how to put multiple SOLO drives on one CANopen network without conflicts. You will set unique node IDs, match the bit-rate, wire the bus correctly, terminate it, watch each node’s health, and coordinate motion across axes. If you want the basics of the protocol first, see our overview of CANopen communication for motors.

One Bus, Many Drives

On a single-drive setup, you talk to one node and the bus is nearly empty. Add a second SOLO and the rules tighten. Every drive now shares the same wire, the same bit-rate, and the same address space. Two nodes with the same ID will clash. A missing termination resistor that one drive tolerated will start to corrupt frames once traffic grows.

So the shift is from “configure a drive” to “design a network.” You still set each node’s drive profile the same way, the modes of operation and the object dictionary. That single-node work does not change here. This article stays on the layer above: the bus itself and how the nodes coexist. If you are planning the wider machine, our guide on multi-axis motor control puts the network in context.

Takeaway: a network is not just more drives. It is shared resources that each node must respect.

Assigning Device Addresses (Node-ID)

Every node on a CANopen bus needs a unique node-ID, a number from 1 to 127. The node-ID sets the COB-IDs the drive uses, so two SOLO units with the same ID will answer the same messages and corrupt each other’s traffic. This is the single most common reason a working single-drive setup breaks when you add the second unit.

On SOLO you set the node-ID by command over the existing link, then store it so it survives a power cycle. Plan the numbers before you wire anything. A simple scheme works best: axis 1 is node 1, axis 2 is node 2, and so on. Keep a small table so you never reuse a value.

Set each ID with the other drives disconnected or unpowered, so you can never write the same value twice by mistake. Then bring the nodes up one at a time and confirm each responds on its own ID.

Takeaway: assign node IDs from a written plan, one drive at a time, and never repeat a number.

Bit-Rate and Bus Length

CANopen trades speed for distance. A fast bit-rate shortens the maximum bus length, because a bit has to travel to the far end and back inside one bit time. Pick the rate that covers your longest cable run with margin, not the fastest one the hardware allows.

These are the common CAN bit-rates and the rough maximum bus length for each. Treat them as guidelines, since cable type and stub length also matter.

The hard rule is simple: every node uses the same bit-rate. One SOLO set to 500 kbit/s on a 250 kbit/s bus will not just fail itself, it will disturb the whole network. Set the rate once, apply it to every drive, and verify before you load motion commands.

Takeaway: choose one bit-rate for your longest run, then set it identically on every node.

Wiring and Termination

Wiring is where good plans turn into noisy buses. CANopen expects a specific physical layout, and the two mistakes that hurt most are bad topology and missing termination.

Daisy-Chain Topology

CAN is a linear bus, not a star. Run one trunk cable and tap each SOLO off it as a short branch, so the nodes sit in a daisy chain from one end to the other. Keep the stubs short, ideally under 0.3 m, because long stubs create reflections that corrupt frames at higher bit-rates. A star layout, where every drive runs back to a central point on its own long cable, is the classic way to build a bus that works at low speed and fails as you speed it up.

120 Ohm Termination at Both Ends

A CAN bus needs a 120 ohm resistor at each physical end, and only at the ends. The two resistors match the cable impedance and stop signal reflections. Leave one off and the bus may still work on the bench with two close nodes, then fail intermittently once the cable gets longer or a third drive joins. This is the classic missing-termination fault: it looks like a software bug but it is a wiring one.

Terminate the two far ends of the trunk, not every node. Middle drives get no resistor. Measure across CAN-H and CAN-L with the bus powered off: a correctly terminated bus reads about 60 ohms, the two 120 ohm resistors in parallel.

Takeaway: wire one linear trunk with short stubs, and put exactly two 120 ohm resistors at the ends.

Keeping the Network Alive

Once the bus runs, you need to know that every node is still there. CANopen gives you two built-in ways to watch node health.

Heartbeat and Node Guarding

Heartbeat is the modern method. Each SOLO sends a short message at a fixed interval, say every 100 ms, that reports its state. The master listens for these messages. As long as the heartbeats keep arriving on time, the node is alive and in the expected state. Node guarding is the older method, where the master polls each node and waits for a reply. Heartbeat is lighter on the bus and is the usual choice for new designs.

Detecting a Dropped Node

Set a consumer timeout on the master that is a little longer than the heartbeat interval, for example 300 ms for a 100 ms heartbeat. If a node’s heartbeat stops arriving, a loose connector, a reset, a power glitch, the master flags that node as lost and can stop motion before a stalled axis does damage. This matters more with every axis you add, because in a multi-drive machine one silent node can wreck a coordinated move.

Takeaway: use heartbeat with a timeout so the master notices a dropped drive within a few hundred milliseconds.

Coordinating Motion Across Drives

Putting drives on one bus is half the job. Making them move together is the other half.

SYNC and Synchronized Setpoints

CANopen provides a SYNC message, a periodic broadcast from the master. Drives configured in synchronous mode apply their new setpoints on the SYNC, so several axes act on the same tick instead of whenever each message happens to arrive. That keeps a multi-axis move coordinated, for example two axes tracing a path together. Send target positions to each node, then issue the SYNC, and the drives step in unison.

CANopen synchronization is good for typical multi-axis coordination at moderate update rates. If your application needs tight, hard real-time sync down to the microsecond, a different protocol like EtherCAT generally fits better. We compare the timing trade-offs in our overview of time-sensitive protocols.

Takeaway: use the SYNC message to apply setpoints together, and step up to EtherCAT only when you need hard real-time.

Who Is the Master?

CANopen needs one master to manage the network: to start nodes, send SYNC, and watch heartbeats. The master is not another drive. It is a controller that runs your application logic. In practice it is usually one of three things.

A PC is common during development, paired with a USB-to-CAN adapter and a software stack. A PLC is the typical choice on a production machine, where it acts as the CANopen master and runs the cell. A microcontroller fits an embedded product that has to coordinate the axes on its own. Each option talks to the drives the same way over the bus, so the choice is about your application, not the CANopen layer.

Whatever you choose, there is one master per bus. The master owns the NMT state of every node, so two masters fighting over the same network is its own failure mode.

Takeaway: pick one master, PC, PLC, or microcontroller, and let it own NMT, SYNC, and heartbeat monitoring.

How SOLO Supports CANopen Networks

SOLO drives support CANopen with the CiA 301 communication profile and the CiA 402 drive profile, so they behave as standard nodes on a mixed network and play well with third-party masters. You can set the node-ID and bit-rate, store them on the drive, and read or write the object dictionary the same way across the range. SOLO also provides libraries and SDKs that handle the common tasks, configuring nodes, sending SYNC, and reading heartbeats, so you spend less time on the protocol plumbing. The aim is to make a multi-drive bus straightforward to bring up rather than a research project. You can find the current libraries and documentation on the SOLO resources page.

Conclusion

Building a CANopen network of multiple SOLO drives comes down to a handful of decisions. Give every node a unique node-ID from a written plan. Set the same bit-rate on every drive, chosen for your longest cable. Wire one linear daisy chain with short stubs and terminate it with two 120 ohm resistors at the ends. Use heartbeat so the master spots a dropped node fast, and use the SYNC message to coordinate motion across axes. Get those right and a multi-axis bus is reliable rather than fragile. When you are ready to wire it up, the SOLO resources page has the libraries and documentation to start.

FAQ