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 www.MicroMessaging.com or www.MicroCANopen.com instead.
Here are some of the biggest differences:
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): https://www.can-cia.org/services/test-center/conformance-test-tool/
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.
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.
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":
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 CANopenIA.com 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 www.MicroCANopen.com.
A: Here is the list of US companies offering CANopen® source code.
| Company, US Headquarters | Product Lines | Google search "CANopen®" (set preferences to "English") |
|---|---|---|
| PHYTEC America LLC (SYSTEC) www.phytec.com (800) 278-9913 Bainbridge Island, Washington |
CANopen® Development Tools CAN Interfaces, CANopen® Modules/Boards, Monitors, Source Code, Starter Kits |
|
| Vector CANtech, Inc. us.vector.com/ (248) 449-9290 Novi, Michigan |
CANopen® Development Tools CAN Interfaces, Monitors, Analyzers, Simulators, Source Code, Configurators |
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 www.phytools.com (206) 451-4327 Bainbridge Island, Washington |
CANopen® Development Tools CAN Interfaces, CANopen® Modules/Boards, Monitors, Source Code, Starter Kits |
|
| Contemporary Control Systems, Inc. www.ccontrols.com (630) 963-7070 Downers Grove, Illinois |
CANopen® Modules/Boards |
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 www.MicroCANopen.com code sizes stay in the 4k-5k area with about 200 bytes of RAM requirement.
A: CANopen® was specified to support both protocol variants, however - switching to the 29-bit identifiers has several consequences:
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:
Notes:
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:
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.
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.
A: The Embedded Systems Academy offers a free online calculator:
http://www.esacademy.com/faq/calc/can.htm
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.
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:
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.