The free CANopen Stack

CANopen Specifications and Device Profiles

CANopen is a high-level protocol for industrial automation. The specifications are managed by a consortium, called CiA (CAN in Automation). There are many "Draft Standards (DS)". The main standards we support are:
DS301 - Application layer and communication profile
DS305 - Layer setting services (LSS) and protocols
DS304 - Framework for safety-relevant communication (on request)
DS306 - Electronic data sheet specification for CANopen (on request)
Beside of these draft standards, there are numerous "Device Profiles". A device profile is a standardized configuration of the object directory and the behavior of specific entries for a specific type of device. Common examples are:
DS401 - Profile for I/O devices
DS406 - Device profile for encoders
DS415 - Device profile for road construction machinery
DS418 - Device profile for battery modules
Due to the fact, that the device profiles define configurations and conventions on the behavior of object directory entries, we can realize them all with the provided CANopen stack.

Standard CANopen Architecture

The following figure shows the principal software architecture of a CANopen device.
Principal CANopen Device Architecture

This CANopen product is transferred to open-source licensing terms. By adopting permissive license terms for the software component, we will make the benefits of this software available to the widest user base possible and give the embedded community a role in future development efforts.

Free for Commercial Use

You can find the source code in our GitHub repository

Note: This is the first component we decide to transfer to open-source. We will give our best to collaborate with the community and maintain the CANopen stack in future development efforts.

The help provided by the community is planned to organize with Issues on GitHub. Additionally, the Professional Service from Embedded Office is still available for a reasonable price.

Supported Modules

Object Directory
You can define static or dynamic object directories which support:
Unlimited number of entries
Integer, String and Domain entries
Customer defined entries
SDO Server
The stack supports a selectable number of SDO server for configuration and device setup:
Expedited transfers
Segmented transfers
Block transfers
PDO Producer
The PDOs are generated and transmitted by using the object directory entries.
Autonomous PDO construction
Application, Signal and Timer Events
Static or dynamic signal mapping
Note: For new designs, using remote requests is not recommended by CiA. Therefore, this kind of transmission is not supported.
PDO Consumer
The stack will receive all configured PDOs and uses the mapping for updating the object directory.
Autonomous PDO deconstruction
Static or dynamic signal mapping
Support dummy PDO signals
SYNC Consumer
Each PDO consumer and producer respects the individual synchronous protocol settings.
Static or dynamic communication settings
EMCY Producer
The emergency producer provides
EMCY History
Standardized Codes
Manufacturer Specific Codes
Heartbeat Producer
The heartbeat producer handles the automatic transmission of the current device state from the NMT client.
Static or dynamic heartbeat configurations
Note: Due to the fact, that node guarding is not recommended for new designs, this module is mandatory.
Heartbeat Consumer
The heartbeat consumer provides a callback interface to the application for notification of heartbeat problems.
0 to 127 heartbeat consumers
Static or dynamic timing configurations
NMT Slave
The NMT client module handles the device network management state machine with some additional features:
Automatic device start
Bootup message enable / disable
Parameter Store & Restore
The parameter module is handling the protocol and provides callbacks for specific media storage:
Store parameter
Restore parameter
Factory reset
LSS Slave
The LSS client provides the protocol for setting and storage of device configurations. Callback functions allow to implement any storage media:
Dynamic setting of node ID
Dynamic setting of CAN baudrate
Software Timer
The stack uses software timers with high resolution for the generation of required timings. Additionally, these software timers are provided to the application as a service:
Any number of application timers
No cyclic interrupt required
Possible use of any hardware timer

Hardware Interface

Interfacing the device-specific CAN controller is abstracted to interface functions. You can use any low-level driver function or direct register access to implement these functions. This will connect the CANopen stack to the implemented interface.

The prototype of the interface functions are:

void    COIfInit  (CO_IF *if, CO_NODE_T *node);
void    COIfEnable(CO_IF *if, uint32_t baudrate);
int16_t COIfRead  (CO_IF *if, CO_IF_FRM *frm);
int16_t COIfSend  (CO_IF *if, CO_IF_FRM *frm);
void    COIfReset (CO_IF *if);
void    COIfClose (CO_IF *if);
We provide an integrators guide, which explains in detail the data structures and the responsibilities of each interface function. Besides to the CAN interface, the CANopen stack requires a timebase. For this timebase, you can choose any hardware timer interrupt source.
Easy to integrate with hardware interfaces
Integration service for your hardware (on request)

Want to learn more...

Customer References

  • Sick Stegmann
Item 1 of 21
Create Your Free Account
Create an account to get access to free Embedded Office services
Access free Embedded Office services
Related Links
How to setup a dynamic CANopen object dictionary
How to use the dynamic CANopen object dictionary
© Copyright 2021. Embedded Office GmbH & Co. KG. All rights reserved. (Version: 9a8d1b0)