CANopen is a CAN based communications system, initially developed for embedded systems used in automation. It is a “Higher Layer protocol”, that runs on a CAN network., It typically uses the same lower physical layer specifications used by CAN (ISO 11898-2), although the the CiA 301 standard does allow for variations to accommodate, for example, different environmental requirements.
CANopen FD is a recent advancement, allowing CAN FD capable infrastructure to be leveraged for higher data throughput, with the same benefits of flexible, robust, and reliable communications.
Here, you can select from a variety of CANopen and CANopen FD software solutions that complement the wide range of (“Lower Layer”) CAN networking infrastructure products available from Traquair:
- CANopen and CANopen FD stacks
- CANopen (FD) toolchain with options for development, monitoring, and analysis
- CAN MultiProtocol Stack (CANopen (FD), EnergyBus, SAE J1939, and proprietary protocols in one application)
- CANopen TCP/IP Gateway (CiA 309-3)
- CANopen Modbus TCP Gateway (CiA 309-2)
CANopen Stacks
CANopen and CANopen FD stacks by emotas are available as CiA 301 compliant ANSI-C software libraries, with options for Basic Master, Master/Slave, and Manager functionality, and supports options for a wide range of CANopen profiles.
Highlights
- ANSI-C CANopen source software libraries
- MISRA-C compliance
- CANopen CiA 301 compliance
- Layer Setting Service (LSS) CiA305 included
- Extension modules for further standards available
- Available for many CAN (*) controller and CPU types
- Comfortable user interface
- Widely scalable and configurable
Developer Requirements
- ANSI-C compiler
- CAN FD controller-based infrastructure required if using CANopen FD products
Scope of Delivery
- CANopen (FD) protocol source code (ANSI-C compatible)
- Ready to run example applications
- User manual and reference manual in electronic format available
- Includes 6 months (for project license) or 24 months (for site license) support by e-mail or phone
- Optional maintenance agreement
- One named user license (for project license) or floating license (for site license) of CANopen DeviceDesigner included
| Service | Basic Slave | Master/Slave | Manager |
| SDO Server | 2 | 128 | 128 |
| SDO Client | 128 | 128 | |
| SDO expedited/segmented/block | ●/●/- | ●/●/● | ●/●/● |
| USDO Server (CANopen FD only) | 2 sessions | unlimited | unlimited |
| USDO Client (CANopen FD only) | unlimited | unlimited | |
| PDO Producer | 32 | 512 | 512 |
| PDO Consumer | 32 | 512 | 512 |
| PDO Mapping | static | static/dynamic | static/dynamic |
| MPDO Dest Mode | ● | ● | |
| MPDO Src. Mode | ● | ● | |
| SYNC Producer | ● | ● | |
| SYNC Consumer | ● | ● | ● |
| Time Producer | ● | ● | |
| Time Consumer | ● | ● | |
| Emergency Producer | ● | ● | ● |
| Emergency Consumer | 127 | 127 | |
| Guarding Master | ● | ||
| Guarding Slave | ● | ● | ● |
| Bootup Handling | ● | ● | |
| Heartbeat Producer | ● | ● | ● |
| Heartbeat Consumer | 1 | 127 | 127 |
| NMT Master function | ● | ● | |
| NMT Slave | ● | ● | ● |
| LED CiA-303 | ● | ● | ● |
| LSS CiA-305 | ● | ● | ● |
| SDO Requester (SRD) CiA-302-5 | ○ | ● | |
| CANopen Router CiA-302-7 | ○ | ○ | |
| Master Bootup CiA 302 | ● | ||
| Configuration Manager | ● | ||
| Flying Master | ○ | ● | |
| Redundancy | ○ | ○ | |
| Safety (SRDO) | ○ | ○ | ○ |
| Multiline | ○ | ○ | ○ |
| ISO-TP Client | ● | ● | |
| ISO-TP Server | ● | ● | ● |
| C#-API-Wrapper für Windows | ○ | ○ | |
| CANopen Profile | |||
| CiA 401 (U8/INT16) | ○ | ○ | ○ |
| CiA 402 | ○ | ○ | ○ |
| CiA 404 | ○ | ○ | ○ |
| CiA 406 | ○ | ○ | ○ |
| CiA 413 | ○ | ○ | ○ |
| CiA 418 | ○ | ○ | ○ |
| CiA 419 | ○ | ○ | ○ |
| CiA 437 | ○ | ○ | ○ |
| CiA 443 | ○ | ○ | ○ |
| CiA 447 | ○ | ○ | ○ |
| CiA 454 | ○ | ○ | ○ |
- ● – included
- ○ – optionally available
A flexible user interface provides functions to evaluate the received data and to use the CANopen (FD) services in the network.
To connect the CANopen (FD) Slave Stack to multiple CAN (FD) controllers and CPU types, a well-defined driver interface is used. Using this driver interface the CANopen stack can also easily be adapted to new CAN controllers or CPU types. Also it is possible to substitute hardware platforms with little effort.
The CANopen (FD) Slave Stack can be used with various Realtime Operating Systems such as ThreadX, FreeRTOS, Keil RTX oder TI-RTOS ,and as well with Linux (SocketCAN, can4linux) or QNX and also with Real time extensions for Windows.
Besides the function API there is also an Mailbox API available for an easy use with multiple tasks resp. threads. Messages between application modules and CANopen (FD) stack are send via mailboxes instead of function calls. This secures a non-blocking communication. An application may consist of several tasks that use the CANopen (FD) Stack in parallel.
To save resources the CANopen (FD) Slave Stack is widely configurable and scalable. The settings for these features are supported by the graphical configuration tool, CANopen DeviceDesigner, which also allows the creation of the object directory and EDS file using a built-in database. As a consequence, changes can be realized fast and easy.
Using the unique CANopen DeviceDesigner valuable development time is saved.
Many ready-to-run examples are provided to make the start with the CANopen (FD) stack as easy as possible. Additionally, a user manual which describes principles and use cases, and a reference manual which describes each API function in detail belongs to the scope of delivery. The stack is constantly tested with the CANopen Conformance Test for compliance with the specification.
The CANopen (FD) Master/Slave Stack leads to fast and easy development of CANopen (FD) master applications.
The Master/Slave stack includes all features and services of the Slave Stack, and adds master features according to CiA302-2, as well as NMT Master functionalities and network management. Several master examples are available to make the first steps in using the complex master functionalities as easy as possible.
Also it is possible to substitute hardware platforms with little effort. The CANopen (FD) Master Stack can be used with various Realtime Operating Systems such as ThreadX, FreeRTOS, Keil RTX, embOS oder TI-RTOS and as well with Linux (SocketCAN, can4linux) or QNX and also with Real time extensions for Windows.
Besides the C function API there is also an Mailbox API available for an easy use with multiple tasks resp. threads. Messages between application modules and CANopen (FD) Master stack are send via mailboxes instead of function calls. This secures a non-blocking communication. An application may consist of several tasks that use the CANopen (FD) Stack in parallel.
Generally, the CANopen manager stack should be used if the CANopen network is very dynamic with a varying number and types of CANopen slaves.
The CANopen (FD) Manager Stack extends CANopen (FD) Master capabilities with additional manager functions according to the CiA specification 302 “Additional Application Layer Functions”. All CANopen master services as defined in CiA 301 are included.
The additional functions to handle dynamic CANopen (FD) networks are:
- BootUp Manager (CiA 302-2)
The bootup manager implements the boot up behavior of a CANopen (FD) network as defined in CiA 302. The manager can be configured to check for mandatory and optional devices according there device types (0x1000) and identity data (0x1018) and inform the application about all devices.
- Configuration Manager (CiA 302-3)
The configuration manager is able to check if the devices are configured as expected and if not, it is able to start a configuration process automatically. Configurations may be read from DCF files or Concise-DCF files.
Additionally, there are optional extension modules for Redundant Networks (CiA 302-6) and Multi-Level-Networking (302-7) available.
The emotas CAN MultiProtocol Stack supports various CAN based protocols in one device. Based on a uniform CAN driver API and a universal CAN Queue Implementation the CAN Multiprotocol Stack supports CANopen (FD), EnergyBus, SAE J1939 and proprietary protocols in one application. Especially gateways between various protocols can be implemented in a fast and straight-forward way.
The configuration is implemented using CAN DeviceDesigner, which is included in the delivery. It comes with various profile and signal databases and allows a comfortable configuration of the services, features and data. All features or the existing stacks are included. For CANopen (FD), all Master and Slave services are available and for J1939 broadcast mechanisms and transport protocols to transfer larger data.
The integration of manufacturer-specific protocols is possible in 2 ways. The first is to use the resource-saving slim API that provides simple functions to send CAN messages or to receive registered CAN messages. The reception is realized by callback functions.
The other way is the Full API. Using this API complex signals can be mapped into CAN messages and the CAN Stack automatically handles timer- or event-triggered transmissions and the application only has to update the data. Using this communication and application may be separated. On reception of CAN message the stack automatically updates the application variables.
The EtherCAN CI-ARM9 Ethernet to CAN gateway is ideally suited to use with the multiprotocol stack software, with Ethernet Interface, 454MHz Freescale ARM9 CPU, and access to embedded software development toolchain for developing own embedded Linux applications on the ARM9 processor.
CAN / Ethernet Gateway
In addition to the EtherCAN CI-ARM9, the Multiprotocol Stack can be used with a large number of microcontrollers and operating systems (Linux, Windows, RTX64…). The CAN DeviceDesigner can be used on Windows and Linux as well.
| Manufacturer | Types |
| ATMEL (Microchip) | ATmega64C, AT90CAN64, AT90CAN128, SAM C21, SAM E54, SAM V71 |
| BOSCH | C_CAN, D_CAN, M_CAN |
| DCD | DCAN FD |
| NXP | Kinetis, S12Z, HCS12, i.MX6 (Linux, INTEGRITY OS), MPC560x, KEAZ128, S32K146, LPC15xx, LPC17xx, LPC40xx, LPC546xx |
| Infineon | XMC4000 (ARM Cortex-M4, MultiCAN), XMC1400 (Cortex-M0) |
| Intel | x86 Architecture |
| Microchip | dsPIC33, PIC24H, PIC32MK |
| NuvoTon | NUC130, NUC140 |
| Renesas | RL78/F14, RX62, RX63N, RX65N, V850E2, RH850/F1L, RH850/F1KH-D8, Synergy S1,S3,S5,S7 |
| Silicon Labs | EFM32GG11 |
| ST Microelectronics | all STM32 (ARM Cortex-M0, Cortex-M3, Cortex-M4, Cortex-M7, bxCAN, M_CAN) including latest STM32G0 & STM32U5, SPC570S |
| Texas Instruments | TMS320, C2000, TMS570 (Hercules), Tiva TM4C129, Sitara AM335x |
| LINUX systems | can4linux, SocketCAN, ECI |
| Windows (x84-64) systems | including support for the CPC Series of CAN PC Interfaces |
The table only lists the families. All providers offer within each family a large number of “family members” that differ in periphery, maximum clock rate or size of housing. In consequence the number of pins and pin assignment also differ.
The protocol stacks can be used with the following compilers and/or IDEs:
- gcc,
- Green Hills Compiler (PPC) by Green Hills Software,
- ARM Keil Compiler,
- IAR Embedded Workbench by IAR Systems,
- Atmel Studio,
- STM32CubeIDE,
- Atollic True Studio,
- MPLAB X,
- Renesas e2Studio with Renesas Compiler
and more. (Not all compilers can be used with all targets, so please inquire in advance for specific CPU/compiler combinations.)
CANopen defines a large number of device or application profiles that specify the interface and behavior of certain devices. Optional extensions are available to support the functionalities of these profiles and to provide the data and events to the application in a preprocessed way:
- CiA 401 – device profile for IO modules
- CiA 402 – device profile for drives
- CiA 404 – device profile for measurement devices and closed-loop controllers
- CiA 406 – device profile for encoder
- CiA 413 – interface profile for truck gateways
- CiA 418 – device profile for batteries
- CiA 419 – device profile for chargers
- CiA 437 – application profile for grid-based photovoltaic components
- CiA 443 – Device profile for sub sea instruments (SIIS Level-2)
- CiA 447 – application profile for add-on devices for passenger cars (taxi, police, …)
- CiA 454 – application profile for Energy Management Systems e.g. in LEVs
emotas CANopen (FD) ToolChain
The CANopen NetworkDesigner by emotas allows for the design a complete CANopen network including all devices and communication relationships. The source code for all components is generated automatically by the tool.
Device and network design
Devices with all their signals and communications (per PDO and MPDO) can be defined with the CANopen NetworkDesigner. The tool creates then the source code for all components within the network. In combination with the emotas CANopen Stack the CANopen NetworkDesigner guarantees a CANopen compliant realization of the design. Heartbeat producer and Heartbeat consumer relations and the connection of Emergency producer and Emergency consumer are also done automatically.
Object linking
For the configuration objects of producer and consumer are shown in a table. Instead of usual CANopen notation “object 0x6041, Subindex 1” the name of the signal e.g. “‘Control Word‘ ” will leads for users to a more convenient handling. With a single click objects of producer and consumer can then be linked. Invalid linkings are impossible, because only valid links that corresponds to the CANopen data type will be displayed. The individual prioritization of links is possible.
PDO-Linking
According to settings done by users the tool sets the PDO configuration with mapping and COB IDs of the CANopen devices. In addition the manual configuration of PDO parameters by experts is possible. Then the CANopen NetworkDesigner takes care of a valid configuration.
The CANopen DeviceDesigner is an easy-to-use tool for fast and cost-saving design of CANopen devices. With a few mouse clicks the object dictionary of the device can be created on the basis of predefined profiles. The CANopen DeviceDesigner creates the object dictionary and initializing functions in C, the electronic data sheet in EDS and XDD format for CANopen FD and a device documentation. Additionally the CANopen DeviceDesigner configures the CANopen stack and CANopen driver under consideration of the device characteristics. So the optimal configuration is given.
Object Dictionary
According to the profiles and input the object dictionary is created as C source code file. This is integrated into the application as interface for the protocol stack. It is possible – when configured accordingly – to access the objects of the object dictionary directly as C variable. Alternatively from the application the access to functions is possible via index and subindex.
CANopen stack configuration and initializing
According to the adjustments and definitions of the object dictionary a configuration and initializing file in C source code is created. This secures that only used services of the CANopen stack will be compiled and initialized. Resource saving configuration is given by that.
Electronic Data Sheet (EDS)
All CANopen devices need an electronic data sheet (EDS) that describes the parameters of the object dictionary electronically. The CANopen DeviceDesigner creates the electronic data sheet in format EDS according to CiA306. The file always reflects the recently generated object dictionary. The automatic generation of the file helps to avoid error prone manual work.
XML Device Description
CANopen FD devices need a XML Device Description according to CiA1311. The CANopen DeviceDesigner generates this format automatically based on the object dictionary definition.
Device documentation
For the object dictionary with all features and descriptions and for further device specific adjustments a device documentation is generated both in HTML and text format. The documentation reflects the recent entries and implementation and is therefore always up to date. It is possible to export the documentation for further use, e.g. as part of the user manual of the device.
Device profiles
Profile files are available for various communication and device profiles of the CiA. A profile file includes templates for all types of objects with the standard attributes and a description of the object. Objects can be imported into the CANopen DeviceDesigner, copied and customized to individual characteristics of devices. When using predefined objects the development time shortens significantly and the error prone work of manual input of data falls away.
Following profile files are available:
- CiA 301 – CANopen application layer and communication profile
- CiA 1301 – CANopen FD application layer and communication profile
- CiA 302 – CANopen additional application layer functions
- CiA 401 – Device Profile for Generic I/O Devices
- CiA 402 – Device Profile for Drives
- CiA 418 – Device Profile for Batteries
- CiA 419 – Device Profile for Battery Charger
- CiA 433 – Application Profile for interior rail vehicle lighting
This list is extended continuously. All mentioned profile files are part of the delivery.
The CANopen DeviceExplorer is a versatile tool for development, testing, diagnostics and service tasks. It provides CANopen master functionalities and allows the analysis and configuration of CANopen devices.
Information about each CANopen device is read from the electronic data sheet of the device, or they can be scanned directly from the device. Using standardized device configuration files (DCF) device configurations can be saved or imported. Additionally, data of entire CANopen networks can be stored in project files. The built-in scripting capability using QtScript allows users to create their own test and control applications with only little effort.
Highlights
- CANopen master functionalities like NMT commands, Heartbeat, Node guarding, SDO client, PDO producer and consumer, SYNC producer, emergency consumer
- Optional LSS master functionality
- Saving and importing of device and network configuration
- Firmware download acc. to CiA 302
- Scripting Plugin to create user specific test or service applications
The CANopen UpdateManager is an easy to handle tool designed for firmware downloads. Apart from direct firmware downloads it offers the opportunity to put firmware files for all devices of a network together, add the configuration data and and create an update package.
This allows service technicians to carry out an automated update of all devices in a network that need an update by simply starting the update package. Additionally, both a CAN backdoor and access to second domain is supported.
An increasing number of CANopen devices need bootloaders to update firmware in the field. The use of a complete CANopen stack for the bootloader is mostly unsuitable, because of the large flash memory footprint.
To avoid this waste of flash memory, emotas developed a new CANopen Bootloader that needs only few memory resources. The bootloader supports the necessary services (SDO, NMT slave, heartbeat producer) and objects. 16 KiB of flash memory are sufficient for the emotas bootloader – and it is still CANopen compatible.
The CANopen Bootloader is available for different 16- and 32-bit micro controllers and can easily be adapted to other targets. SDO block transfer is optionally available as well. It is delivered as ANSI-C source code and thus can be extended by customers e.g. with a password protection mechanism, firmware encryption or a manufacturer-specific back door.
CANopen Gateways
The emotas CANopen TCP/IP Gateway software application is a universal TCP/IP to CANopen gateway according to the CiA 309-3 specification. It is used for providing remote access to CAN based CANopen resources via TCP/IP, using a CAN connected Windows or Linux PC, or on a Linux based CAN Gateway.
The gateway software is available in a variety of builds and configurations, with project or site level software licensing, and options for provided customer and application specific extensions.
Low cost binary versions are also available for Windows or Linux based PCs using CPC PC Interfaces and Adapters, or for the rack-mountable EtherCAN CI-ARM9 CAN to Ethernet Gateway
CANopen Services
The CANopen component of the gateway consists of the emotas CANopen Master Stack.
CANopen services according to CiA309-3 specification are supported:
- SDO Client (data types from 8 ..32 bit, strings and domains)
- NMT commands
- PDO Producer
- PDO Consumer
- Node Guarding Master
- Heartbeat Consumer
- Heartbeat Producer
- Emergency Consumer
- LSS Master (LSS FastScan included)
Further CiA309-3 commands for the configuration of the gateway are also available.
The CANopen Modbus TCP gateway is compliant with the CiA 309-2 specification. It is used for providing Modbus TCP network client access to CAN based CANopen resources, using a CAN connected Windows or Linux PC, or a Linux based CAN Gateway.
It is available in a variety of builds and configurations, with project or site level software licensing, and options for provided customer and application specific extensions.
Low cost binary versions can also be provided for Windows or Linux based PCs using CPC PC Interfaces and Adapters, or for the rack-mountable EtherCAN CI-ARM9 CAN to Ethernet Gateway.