CANopen example fails when the device type is wrong

Why does my CANopen example refuse to run?

The example targets the controller's own CANopen interface, and that node must be declared as CANopenLocalDevice; your project declares it as CANopenRemoteDevice, so the node role does not match the configuration the example was written against, and the download or the first communication fails.

You meet the problem as one of two symptoms, and both point at the same declaration:

• The download stops on the device entry. The example's node configuration was written for a local device; the tree offers an external one, and the download goes no further.
• The download completes and the bus stays silent. The logic runs against a declaration of an external slave waiting for a master, so no telegram moves and nothing answers.

A third sign sits in the editor. The example wants the CANopen Local Device Editor, the configurator for the controller's own node that ships with the CANopen Device SL package; a remote entry opens the EDS-based editor for an external device. If the refusal names the runtime device and the CANopen entry is already correct, that is a different mismatch with its own fix: see fix a PLC runtime device mismatch safely.

What is the difference between CANopenLocalDevice and CANopenRemoteDevice?

CANopenLocalDevice declares the CANopen device that runs on the controller itself, with its own object dictionary; CANopenRemoteDevice declares an external node on the bus, described by an EDS file and managed by a master, and the two roles instantiate the stack and the dictionary differently.

A remote device is another box on the cable: a drive, an I/O coupler, a sensor block. The controller talks to it as the master and needs that box's EDS file to know its objects. The local device is the controller wearing the device hat: the example addresses its objects directly, and the editor that configures it is the CANopen Local Device Editor.

The role decides three things: which editor opens, which settings you can reach, and which EDS applies. An example written for the local role cannot find its objects under a remote declaration, which is why the fix is the swap; no parameter edit gets around it.

How do I swap the tree entry to CANopenLocalDevice?

Replace the device entry in the project tree so it reads CANopenLocalDevice, re-enter the node ID and bit rate the example sets, and leave every other part of the example untouched; the swap changes the node's role, not its application logic.

1. Read the node ID and the bit rate out of the example's node configuration before you change anything, because you will enter them again after the swap. In these examples, the rate to expect is 250 kbit/s.
2. Select the CANopen entry in the tree and use the command that replaces one device with another from the Device Repository; in current versions it sits on the entry's right-click menu. Choose the local CANopen device so the entry reads CANopenLocalDevice.
3. Open the swapped node and set the node ID and the bit rate from step 1.
4. If the example also carries external nodes, a drive or an I/O block, leave their entries and their EDS files alone; only the controller's own node changes role.
5. Save, download, and run the checks below.

Where do I get the EDS file for the node?

Export it from the Device Repository: the repository already holds the device description your project uses, so the exported file matches the configured node exactly, and any external master or configuration tool receives a sheet that agrees with what the controller runs.

The export and the install live in the same place, Tools > Device Repository. Installation runs the other way, for third-party devices: Tools > Device Repository > Install, pick the maker's *.eds file, and the device turns up under Fieldbusses > CANopen > Remote Device, ready to add under your master. Take those files from the device maker or its distributor, never from a file-sharing site.

Why export from the repository instead of hunting a download? Version match: a sheet exported from the repository is the same definition the project configures, so it cannot disagree with the node. If a supplier EDS refuses to install at all, the file's protocol profile is the first thing to check; this walkthrough of EDS installation failures and conformance checks covers the usual reasons.

Which node ID and bit rate does the swap change?

Two settings: the node ID, a unique number from 1 to 127 in the CANopen scheme where 0 is invalid, and the bus rate, which every node on the cable must share; the rate to check in these example projects is 250 kbit/s.

The 250 kbit/s value sits inside the rate set CANopen standardizes, which runs from 10 kbit/s to 1000 kbit/s. Each rate carries a maximum trunk length in the CiA cabling figures:

Drop lines subtract from the trunk budget at their attachment point. Every node must run the same rate, because CAN has no negotiation step. Two nodes must never share an ID: identical IDs corrupt each other's traffic.

What does the fix look like on a worked example?

A palletizer example will not download; its tree shows CANopenRemoteDevice where the example wants the controller's own node, so the swap, the re-entered settings and a 40 m cable check against the 250 m limit at 250 kbit/s carry it through to a running node.

The example ships with its CANopen configuration written for the controller's own port. The tree in front of you was built by adding a CANopen device from an EDS file, so the entry reads CANopenRemoteDevice. Walk it through:

1. Swap the entry to CANopenLocalDevice.
2. The example's node configuration sets node ID 10 at 250 kbit/s; enter both in the swapped node's editor.
3. Measure the trunk: 40 m from the controller to the farthest drop. The CiA figure at 250 kbit/s is 250 m, so the margin is 250 m - 40 m = 210 m.
4. The example carries one remote I/O block at node ID 20, its EDS installed through Tools > Device Repository > Install. ID 20 differs from ID 10, and both sit inside the 1 to 127 range.
5. Download.

Result: the download completes, the local node answers at 250 kbit/s, and the I/O block at ID 20 comes up beside it. Nothing in the example's logic changed; the declaration changed, and the two settings followed it.

How do I check the node after the swap?

Watch the node status on a fresh start: a healthy local node reaches the operational state and answers SDO reads from the master, and anything short of that points back at the ID, the rate or a wiring fault before it points at the example.

• Node status after boot-up. The states, what each one means, and the guard timer that keeps a node honest on the wire are laid out in the CANopen node status and guard timer article.
• SDO read of a known object. If the dictionary answers, the node is live. Large parameter blocks move faster with SDO block transfer, and the SDO block transfer article covers support and troubleshooting.
• Frames on the wire. A CAN analyzer set to 250 kbit/s shows whether both ends produce traffic at the same rate; a node with a mismatched rate shows nothing.
• Process data once operational. The example's variables move, and the application does what its logic says.

When is CANopenRemoteDevice the right declaration?

When the node is genuinely external: a drive, an I/O coupler or a sensor block that the controller manages as master, described by the maker's EDS file and added under Fieldbusses > CANopen > Remote Device; the controller's own node stays CANopenLocalDevice.

Vendor examples pick one role to show one job. Examples that exercise the controller's own CANopen device use the local role; examples that demonstrate a master managing external slaves use the remote role with EDS files. Match the declaration to whoever owns the object dictionary you are about to address, and the example runs as printed.

Recommendation: When a vendor CANopen example refuses to run, treat the tree's device declaration as the first suspect. If the example drives the controller's own CANopen port, swap the entry to CANopenLocalDevice, re-enter the example's node ID and its 250 kbit/s bus rate, and export the EDS from the Device Repository for any external tool. Add remote entries only for nodes that are separate boxes with their own maker's EDS.

Questions