CANopen protocol stack
CANopenNode is free and open source CANopen protocol stack.
CANopen is the internationally standardized (EN 50325-4) (CiA301) higher-layer protocol for embedded control system built on top of CAN. For more information on CANopen see http://www.can-cia.org/
CANopenNode is written in ANSI C in object-oriented way. It runs on different microcontrollers, as standalone application or with RTOS.
Variables (communication, device, custom) are collected in CANopen Object Dictionary and are accessible from both: C code and from CANopen network.
CANopenNode homepage is https://github.com/CANopenNode/CANopenNode
This is version 4 of CANopenNode with new Object Dictionary implementation. For older versions
All code is documented in the source header files. Some additional documents are in
To generate complete html documentation, run doxygen in the project base directory:
sudo apt install doxygen graphviz pdf2svg; doxygen > /dev/null
Complete generated documentation is also available online: https://canopennode.github.io
Tutorial, demo device and tests are available in CANopenDemo repository.
Report issues on https://github.com/CANopenNode/CANopenNode/issues
Older discussion group is on Sourceforge: http://sourceforge.net/p/canopennode/discussion/387151/
Contributions are welcome. Best way to contribute your code is to fork a project, modify it and then send a pull request. Please follow the Recommended C style and coding rules, like indentation of 4 spaces, etc. There is also a
codingStylefile with example.
Flowchart of a typical CANopenNode implementation: ~~~ ----------------------- | Program start | ----------------------- | ----------------------- | CANopen init | ----------------------- | ----------------------- | Start threads | ----------------------- | | | -------------------- | -------------------- | | |
| CAN receive thread | | Timer interval thread | | Mainline thread | | | | | | | | - Fast response. | | - Realtime thread with | | - Processing of time | | - Detect CAN ID. | | constant interval, | | consuming tasks | | - Partially process | | typically 1ms. | | in CANopen objects: | | messages and copy | | - Network synchronized | | - SDO server, | | data to target | | - Copy inputs (RPDOs, | | - Emergency, | | CANopen objects. | | HW) to Object Dict. | | - Network state, | | | | - May call application | | - Heartbeat. | | | | for some processing. | | - LSS slave | | | | - Copy variables from | | - Gateway (optional): | | | | Object Dictionary to | | - NMT master | | | | outputs (TPDOs, HW). | | - SDO client | | | | | | - LSS master | | | | | | - May cyclically call | | | | | | application code. |
All code of the CANopenNode is non-blocking. Code in source files is collected into objects. Parts of the code can be enabled/disabled, so only files and parts of code can be used, which are required for the project. See stack configuration in 301/CO_config.h file.
For most efficiency code can run in different thread as seen in above flowchart. This is suitable for microcontrollers. It is also possible to run everything from single thread, as available on Linux devices. Code includes mechanisms, which triggers processing of OD objects when necessary.
In CANopen initialization section all CANopen objects are initialized. In run time CANopen objects are processed cyclically.
Files CANopen.h and CANopen.c is a joint of all CANopen objects. It may seems complex, but offers some flexibility and is suitable for most common configurations of the CANopen objects. CANopen objects can be defined in global space or can be dynamically allocated. Object dictionary can be used default (OD.h/.c files), but configuration with multiple object dictionaries is also possible by using the #CO_config_t structure. CANopen.h and CANopen.c files can also be only a reference for more customized implementation of CANopenNode based device.
Object Dictionary is a collection of all network accessible variables and offers most flexible usage. OD variables can be initialized by object dictionary or application can specify own read/write access functions for specific OD variables. Groups of OD variables are also able to be stored to non-volatile memory, either on command or automatically.
Object Dictionary is one of the most essential parts of CANopen.
To customize the Object Dictionary it is necessary to use external application: CANopenEditor. Latest pre-compiled binaries are also available. Just extract the zip file and run the
EDSEditor.exe. In Linux it runs with mono, which is available by default on Ubuntu. Just set file permissions to "executable" and then execute the program.
In program, in preferences, set exporter to "CANopenNode_V4". Then start new project or open the existing project file.
Many project file types are supported, EDS, XDD v1.0, XDD v1.1, old custom XML format. Generated project file can then be saved in XDD v1.1 file format (xmlns="http://www.canopen.org/xml/1.1"). Project file can also be exported to other formats, it can be used to generate documentation and CANopenNode source files for Object Dictionary.
If new project was started, then
DS301_profile.xpd may be inserted. If existing (old) project is edited, then existing
Communication Specific Parameters may be deleted and then new
DS301_profile.xpd may be inserted. Alternative is editing existing communication parameters with observation to Object Dictionary Requirements By CANopenNode in objectDictionary.md.
To clone, add or delete, select object(s) and use right click. Some knowledge of CANopen is required to correctly set-up the custom Object Dictionary. Separate objects can also be inserted from another project.
CANopenNode includes some custom properties inside standard project file. See objectDictionary.md for more information.
CANopenNode can run on many different devices. Each device (or microcontroller) must have own interface to CANopenNode. CANopenNode can run with or without operating system.
It is not practical to have all device interfaces in a single project. Interfaces to other microcontrollers are in separate projects. See deviceSupport.md for list of known device interfaces.
RTR (remote transmission request) is a feature of CAN bus. Usage of RTR is not recommended for CANopen and it is not implemented in CANopenNode.
When node is started (in NMT operational state), it is allowed to send or receive Process Data Objects (PDO). If Error Register (object 0x1001) is set, then NMT operational state may not be allowed.
All CANopen objects calculates next timer info for OS. Calculation is based on various timers which expire in known time. Can be used to put microcontroller into sleep and wake at the calculated time.
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.