CAN (Controller Area Network, CANbus) and CANopen®
FAQ (Frequently Asked Questions)

This is a collection of Frequently Asked Questions concerning CAN and CANopen® along with their answers. Some of them were collected from the CAN mailinglist (, others were submitted through the tutors of ESAcademy (

See our main page for a listing of online resources (articles and online training classes) and books.


Q: When and why would I need a higher-layer protocol such as CANopen® instead of plain CAN?

A: CAN by itself only provides a method of exchanging up to 8 data bytes using message frames that have an identifier. Once you sit down and specify which identifier is used for which purpose - and what the contents of each message means (data types, byte order, variables) you are already starting to specify your own higher-layer protocol.

As soon as a certain number of nodes, messages and network variables are involved, an in-house specification of that higher-layer protocol needs to be written and maintained.

With CANopen® all of that work has already been done. Instead of re-inventing existing technology, engineers can take advantage of CANopen® and adopt existing technology.

Due to the "openness" of CANopen®, it is even possible to pick and select the features required by an application and skip the unwanted ones. CANopen® literally reduces an in-house specification to a document that states which features of CANopen® are used.

Most commercial CANopen® source codes support the selection of features via "#define" statements in the source code.

If you are not yet certain if you want to use CANopen® or implement an in-house higher-layer protocol, consider using or instead.

Q: How does CANopen® compare to DeviceNet?
A: As both these protocols are based on CAN, the basic communication features are very similar

Here are some of the biggest differences:

  • DeviceNet allows for up to 64 nodes in a network segment, where CANopen® allows for 127.
  • DeviceNet has a much stricter specification for the physical layout, this support a higher-level of off-the-shelf and plug-and-play support. DeviceNet components from very different manufacturers can easily be integrated into a complete system.
  • CANopen® on the other hand is much more flexible on both the physical implementation, but also on the communication features supported. CANopen® is "open" and allows a high level of customization and optimization towards a specific application, to achieve best possible communication performance.

Q: Do I need to have my node CANopen® conformance tested?
A: If you are selling your node to 3rd parties as CANopen® compliant or if you purchase a CANopen® node from a 3rd party a CANopen® conformance certificate gives both parties the extra insurance that the part actually behaves as specified. So if 3rd parties are involved (either selling or buying) CANopen® nodes should really be certified.

For in-house applications where all CANopen® nodes come from the same manufacturer a conformance test would not really be required. However, if several engineers, teams or departments are involved a conformance test can help especially in the debug and test phase to confirm that a particular node really behaves as expected.

The only difference in these two scenarios is that if 3rd parties are involved the conformance testing should be done by an independent 3rd party such as the CiA (CAN in Automation):

Q: Is 127 "really" the maximum number of nodes in a CANopen® network?

A: Not "really" :-)

The original CANopen® specification is on one hand limited to a maximum of 127 nodes, however - it was kept "open" enough to provide room for extensions. Actually so much room that several, very different solutions exist for this problem. There are application-specific, customized versions of CANopen® networks installed that have more than 127 nodes. Contact your favorite CANopen® consultant to learn how a support of more than 127 nodes could be best implemented in your application.

Q: Can the node IDs in a CANopen® network be auto-assigned?

A: Although it is not part of the original standard there are several, application specific ID claiming implementations, including one suggested in one of the application profiles (door control). Depending on the application requirements, several options are available.

Pure software solutions usually require that each node has a "unique number of bytes", either in form of a serial number or a random number generator. Depending on bus speed and number of nodes, the claim-cycle may take several seconds to execute.

Other applications might require that the node ID is related to the physical location in the network. So if the node IDs should really be 1, 2, 3, ... sorted by their physical location, then additional hardware is required.

We have seen several implementations that use an additional wire in the cabling for this purpose. And there are several options on how to use this wire - one is creating a daisy-chain (going in and out of each node, with each node having the possibility to switch the signal for the next node in the chain). In this case the node "closest" to the master will be configured first. Once it is configured, it enables the next node in the chain.

Contact your favorite consultant for help with any of the methods above.

Q: What is the identifier of a node, message and or variable?

A: In CAN and CANopen® there are several identifiers used for different purposes. Beginners tend to mix-up these, so pay close attention to the different meaning of the word "identifier":

  1. On the CAN level (looking at CAN messages on the bus, generated by a CAN controller, no higher-layer protocol involved), the "identifier" is the CAN message identifier. Version CAN 2.0A allows for an 11-bit ID ID (up to 2048 different identifiers), version CAN 2.0B for a 29-bit ID.
  2. Higher-layer protocols such as CANopen® use node identifiers to address a specific node in the network. The node ID is in the range of 1 to 127 in CANopen® and 0 to 63 in DeviceNet. Sometimes, the node-ID is embedded into the CAN ID. The pre-defined connection set of CANopen® places the node ID into the lower 7 bits of the 11-bit CAN ID.
  3. In CANopen®, network variables have their own identifier. All network variables are located in the object dictionary, which is a look-up table using a 16-bit index and a 8-bit subindex. The index and subindex are used to identify one specific network variable in one specific node. A typical access (SDO access, service data object) to such a variable uses a CAN message that contains a node-ID within the CAN-ID and the index and subindex (indexing a variable in the object dictionary) within the data field.

Implementation Issues

Q: How do I implement CANopen®?

A: Depending on your expertise you might be tempted to simply buy the specification and start implementing it. Unless you already have a great deal of expertise with CAN and at least another higher-layer protocol you should really evaluate this option carefully. If the project demands a limited CANopen® implementation not requiring 100% CANopen® compliance, then this might be a possible route.

However, as soon as more complex CANopen® features or a 100% CANopen® conformance are required, the recommendation is to not start from scratch again. The specification unfortunately does not contain all details and many issues will only show up once the CANopen® conformance test is started. Buying somebody else's implementation that already passed the conformance test is a great shortcut shaving several months of your project.

The comparison overview about different implementation methods at is probably a little biased but gives a fair overview about the pros and cons of each method.

Another alternative for low-end CANopen® nodes is

Q: Which US companies offer CANopen® source code?

A: Here is the list of US companies offering CANopen® source code.

Company, US Headquarters Product Lines Google search "CANopen®"
(set preferences to "English")
(800) 278-9913
Bainbridge Island, Washington
CANopen® Development Tools
CAN Interfaces, CANopen® Modules/Boards, Monitors, Source Code, Starter Kits

Vector CANtech, Inc.
(248) 449-9290
Novi, Michigan
CANopen® Development Tools
CAN Interfaces, Monitors, Analyzers, Simulators, Source Code, Configurators

Q: Which US companies offer CANopen® chips or modules for embedded integration?

A: Here is the list of US companies offering CANopen® chips or modules for embedded integration.

Company, US Headquarters Product Lines Google search "CANopen®"
(set preferences to "English")
phytools, LLC
(206) 451-4327
Bainbridge Island, Washington
CANopen® Development Tools
CAN Interfaces, CANopen® Modules/Boards, Monitors, Source Code, Starter Kits

Contemporary Control Systems, Inc.
(630) 963-7070
Downers Grove, Illinois
CANopen® Modules/Boards

Q: What are the memory requirements for a CANopen® communication protocol stack?

A: The memory requirements differ a lot depending on the microcontroller architecture used and the CANopen® features required by a particular node/application.

The nice thing about CANopen® is, that the set of mandatory functionality is very small, all others are optional. So a CANopen® node can be build with exactly the required set of communication functions.

Although a minimal bootloader fits into 2k of code, this doesn't really implement a true CANopen® node as there is no process data.

On an 8-bit microcontroller, take the following generalized rule-of-thumb:

Generic implementations require some 12k-20k of code space and about 500 to 1000 bytes of data memory. An implementation highly optimized towards a specific microcontroller can use 25% less code and data memory.

UPDATE (October-2002): With code sizes stay in the 4k-5k area with about 200 bytes of RAM requirement.

Q: Why do most CANopen® applications use CAN 2.0A (11-bit identifiers) and not CAN 2.0B (29-bit identifiers)?

A: CANopen® was specified to support both protocol variants, however - switching to the 29-bit identifiers has several consequences:

  1. As only the address field is extended, but not the data field, the overall available data bandwidth decreases. More bits of overhead were added to each message.
  2. The overall reliability decreases, as the CRC checksum in each message now needs to cover 18 bits more.
  3. The worst case delay for high priority messages becomes longer. Even a low priority message can not be interrupted or aborted once it won arbitration to the bus. And the maximum length of messages on the bus was now increased by 18 bits.

Physical stuff

Q: How do I connect a CAN controller to the bus?

A: The most common form is to use a differential transceiver. One of the most popular transceivers is the NXP PCA82C251 high-speed, differential signal transceiver. Datasheet at:


  • The "Tx" pin of the CAN controller goes to the "Tx" pin of the transceiver.
  • The "Rx" pin of the CAN controller goes to the "Rx" pin of the transceiver.
  • The "Rs" (slope) control of the transceiver is set to GND (high speed mode) in most applications. If EMI is a problem in your application, consider other operating modes.
  • The "Vref" is an output of the transceiver that in many applications can be left unconnected.

Q: How do I calculate the CAN bit timing of my CAN controller?

A: Either read the data sheet of your CAN controller and go from there...

...or take a short cut and use CAN Bit Time Calculation.

CAN Bit Time Calculation is a JavaScript driven table/website by Heinz-Jürgen Oertel that supports the following CAN controllers:

  • Philips 82C200, NXP SJA1000
  • Intel 82527 (and derived from it Infineon (Siemens) C167CR, C515C, XC161C, XC164C, TwinCAN SAK82C900)
  • Fujitsu (reported from Ralf Ebeling) and acknowledged by us for MB9054x
  • Dallas 80c390 Dual CAN
  • Toshiba TCAN
  • Freescale msCAN (HCS12) and Frescale MCA
  • Holt Inc, H3110 stand alone CAN controller (with transceiver)

Q: I just implemented my node - and it does not transmit?!

A: When running your first tests, ensure that your physical network layout is correct and that you have at least one other node connected to the network operating at the same speed / baudrate.

A CAN controller cannot transmit a single message unless it is acknowledged by at least one other CAN controller. So the wiring (don't forget the termination resistors at both ends) and another node must be in place before you can test your node.

If you are using a CAN monitor or analyzer as the second node, you can confirm that your node is set to the right baudrate by transmitting a message to it from the CAN monitor or analyzer. If the monitor or analyzer is the only node in the system besides yours, try to transmit a message from it. If your controller is correctly initialized it will acknowledge the message allowing the message to be transmitted by the monitor or analyzer. Otherwise the monitor or analyzer will show a high bus load r another error.

Q: How can the data bandwidth of a CAN/CANopen® network be increased?

A: There are several options that can help to increase the bandwidth.

As the maximum possible bit rate depends on the maximum bus length, see if you can make your network shorter - and faster. Still, the maximum is about 1MBit.

If you need the longer distance, see if a bridge/gateway can solve the problem. An existing 125kbit bus layout stretching to the maximum possible length can usually be doubled in speed if a bridge/gateway is introduced - separating the bus into two segments of 250kbit each.

Finally, there are several microcontrollers with multiple CAN interfaces. Consider using multiple CAN/CANopen® networks to multiply the overall bandwidth.


Q: How do I calculate worst case message delay times and data bandwidth?

A: The Embedded Systems Academy offers a free online calculator:

After entering the desired baud rate, the length of the shortest CAN message (enter number of data bytes in your shortest PDO) and the length of the longest CAN message (enter 8 - SDO message is always 8 bytes long) hit the "Calculate" button.

The form gets updated and shows you an approximation of the expected timing behavior. It is an approximation only, as CAN uses stuff bits - so the exact message length varies slightly with data contents.

Q: How fast is a CAN/CANopen® I/O cycle? (read INPUT trasmit via CANopen®, write OUTPUT)

A: Unfortunately there are MANY factors going into this formula. If you are looking at an entire I/O cycle, you have the following potential delays:

  1. Input scan/recognizing loop until setting CAN transmit bit.
    Depending on microcontroller performance and priorities this will be some 200us or more. With input filters, polarity changes or configurable "mapping" (which input goes to which CAN message) as provided by CANopen® this might more than double.
  2. CAN message on bus delay.
    All delays here are multiple bit times. At 1Mbit, a single bit time is 1us. At 250kbit, bit time is 4us. If there is currently a message on the bus, it cannot be aborted/interrupted. The maximum delay until any node gets a chance to try to arbitrate the bus depends on the longest possible message on the CANbus. With CANopen® that is typically about 135 bit times.
  3. CAN arbitration delay.
    Assuming the message of our node gas the highest priority, this delay will be zero. However, each message currently waiting to be transmitted anywhere on the bus having a higher priority will get the bus befor our node. Each message delay is another 47 to 135 bit times.
  4. Actual CAN transmit time
    See   Some 47 to 135 bit times.
  5. CAN receive interrupt delay in Output module.
    Depending on microcontroller performance and interrupt priorities this will be some 100us or more. With output filters, polarity changes or configurable "mapping" (which CAN message contents goes to which output is configurable) as provided by CANopen® this might more than quadruple.
    Many commercial CANopen® stacks leave the CAN receive interrupt before applying the output "sometime" later in the background task, making the worst-case MUCH longer.

MINIMUM TOTAL (1Mbit example, highest priority):
200us + 135us + 0 + 60us + 100us = 495us

"REALISTIC" TOTAL (1Mbit example, medium priority):
300us + 135us + 135us + 60us + 300us = 930us

Conclusion: A complete I/O cycle can be completed within 1ms on a CANbus running at 1Mbit, if the priorities (interrupts on controllers and CAN message) are fairly high.

As soon as the bus' bitrate is slowed down or a lot of CANopen® protocol functionality is added, the total I/O cycle time will be closer to 2-3ms.

Do you have more questions - or - comments on the answers?
Submit them!