CANopen and Kvaser

CANopen – a higher-layer CAN communication protocol – is widely used as a standardized and highly configurable solution for embedded networks in real-time industrial applications like robotics, medical, transportation, automotives and aerospace.

Kvaser’s CAN interfaces, along with Technical Associate software, provide a secure way to communicate with and configure your CANopen application.

CANopen-compatible interfaces

Kvaser CAN interfaces are an ideal solution for CANopen communication, featuring:

  • Swedish-made hardware, with high performance features and exacting production, ensure long-time reliability. A true fit-and-forget solution.
  • Enclosed interfaces or PCI-based boards for embedded networking – the choice is yours.
  • A free, universal and forward-compatible API simplifies software integration.
Search CANopen Interfaces >>

Why and how to migrate to CANopen FD?

Torsten Gedenk, from emotas Embedded Communication GmbH, looks at the key elements of migrating from CANopen to CANopen FD.

Read Blog

The right software for your application

Kvaser network of Technical Associates provide industry-trusted solutions for managing CANopen systems, configuring servos, developing software, and more.

SOFTWARE TOOLS

SYSTEM DESIGN & INTEGRATION SERVICES

CANopen PROTOCOL STACKS

CANopen FD PROTOCOL STACKS

SERVO CONFIGURATIONS

Copley Controls
Xenus, Accelnet, Stepnet Product configuration
copleycontrols.com/en/products

Elmo Motion Controls
Composer – Servo drives tuning / auto tuner software for SimplIQ and ExtrIQ servo drives
elmomc.com/product/composer

Advanced Motion Controls
DigiFlex® DriveWare software for setup and configuration of digital servo drives
a-m-c.com/experience/products/software/driveware

Learn More

Intro to the CANopen Specification

CANopen is a higher-layer (Layer 7) CAN communication protocol that is supplemented by a set of device profiles. It is being widely used as a standardized and highly configurable solution for embedded networks in real-time industrial applications, robotics, medical, transportation, automotives and aerospace. The CANopen device profile family specifies standardized communication mechanisms and the needed device functionalities for various applications. CAN in Automation (CiA) International Users and Manufacturers Group maintains the CANopen standard.

Advantages of CANopen

  • Standardized for embedded applications with highly flexible configuration capabilities through application and by Network Event Service.
  • Standardized device, interface and application profiles facilitate easy integration of complete CANopen systems with high modularity and provides interoperability and interchangeability.
  • Highly standardized protocol supported by a number of international vendors.
  • Real-time data exchange, synchronous and asynchronous, cyclic and acyclic and event driven.
  • Object Dictionary with efficient addressing scheme that allows system engineer and application developer to extend upon the CANopen base profiles and also provides extended device configuration and diagnostics capabilities.
  • SDO messaging coupled with Object Dictionary provides system designers means for device configuration through network.
  • Various communication objects that allow system designers to program the desired network functionality for process data communication, error indication and network control.
  • Efficient synchronization through dedicated SYNC and TIMESTAMP objects.
  • Robust node monitoring and diagnostics through Node Guarding.
  • Efficient and flexible state machine implementation for robustness, fault tolerance and recovery.

Watch the update on “CANopen FD”, presented by the CAN in Automation group.

CANopen Profiles

CiA is maintaining the CANopen device and communication profile specifications through a series of documents. CiA documentations for CANopen belong to 3 categories:

  1. CiA specifications – functionalities for implementing protocols and profiles in hardware and software.
  2. CiA recommendations – information about the most suitable solutions.
  3. CiA implementation and user guidelines – description about how to use the CiA specifications and recommendations.

The basic profile is defined in the document CiA 301 Specification. It is named as “CANopen application layer and communication profile” and specifies the CANopen application layer. The specifications include:

  • Data types, encoding rules and Objects in the CANopen Object Dictionary
  • CANopen communication services and protocols
  • CANopen network management services and protocols
  • CANopen communication profile – the physical layer
  • The predefined communication object identifier connection set, objects related to Emergency, Timestamp and Sync communication objects.

The basic CiA 301 profile specification is supplemented and extended by other CiA documents to specify device, application and interface profiles for more specialized devices and functionalities.

To name a few:

  • CiA 302 –  CANopen additional application layer functions
  • CiA 303-1 – Cabling and connector pin assignment
  • CiA 303-3 – Indicator specification
  • CiA 306 – CANopen electronic data sheet specification
  • CiA 309 – CANopen access from other networks
  • CiA 315 – CANopen generic frame
  • CiA 401- CANopen device profile for generic I/O modules
  • CiA 402 – CANopen device profile for drives and motion control

CANopen Device Model

Every CANopen device adheres to a generic device model so that different devices are described by the same CANopen standard. The three components of the CANopen device model are:

  • Communication
  • Object dictionary
  • Application
CANopen_Device_Model

Communication

CANopen uses different communication models for message transmission between nodes:

Producer/Consumer model: it is a broadcast connection and works in push mode (producer node sends information to the consumer node without any specific request) and pull mode (consumer node requests specific information from the producer node).

Client/Server model: uses the SDO protocol by which client node requests data (object dictionary index) from the server node and the server node then responds by sending the object content at the specified index.

Master/Slave model: the master node can send to or request data from slave nodes any time. Eg: NMT protocol communication.

CANopen communication unit consists of necessary communication interfaces and protocol software to provide transmission and reception of communication objects through the bus between nodes. Different CANopen communication objects are used for implementing various types of communications like process data, network management, node monitoring, synchronization signals error control and emergency messages. These objects and their description are listed in the table to the right.

Screen Shot 2020-02-10 at 6.48.02 PM

The CANopen Frame

A CANopen frame consists of the following fields:

  • 11-bit CAN frame id, also known as the CANopen communication object identifier (COB-ID). It is further divided into 4-bit function code (representing a CANopen communication object) and 7-bit node id.
  • 1-bit Remote Transmission Request (RTR).
  • 4-bit data length
  • 0 – 8 bytes of data
Screen Shot 2020-02-10 at 6.58.47 PM

Object Dictionary

The Object Dictionary (OD) is the central concept around which CANopen is built. It is a grouping of pre-defined CANopen objects and uses indexes and sub indexes for object access through the network. The object dictionary is the interface between the application and the device and provides methods for the configuration and communication with the device. Information stored in the object dictionary as object entries include:

  • Communication and application profile parameters
  • Standardized device profile parameters
  • Manufacturer specific device profile parameters
  • Device profile static data types
  • Device profile complex data types
  • Complex and static data types
  • Manufacturer specific data types
  • Etc

It is clear from the above object descriptions that a manufacturer can enhance his device’s functionality by extending the standard device functionality specified by the standard device profile and data type specifications. He can do it by adding his own manufacturer specific profiles and data types in a pre-defined fashion as guided by the CANopen standards.

The fields in the object dictionary entries include:

Main Index: 16-bit index that directly points to entries in the object dictionary. For simple variables, the index refers directly to the variable value and for complex types, this point to the entire records or arrays.

Sub index: 8-bit sub index that points to the individual data fields like array entries or record values in a complex data structure that is pointed to by the main index.

Object: the symbolic name of the type of the Object in the entry. Eg: VAR, ARRAY, RECORD, etc.

Name: the string describing the entry.

Type: data type modifier of the entry. Eg: UNSIGNED32, BOOLEAN, etc.

Attribute: access right value for this entry. Eg: read-write, read-only, write-only

Mandatory/Optional: whether it is mandatory or optional for the device to implement this particular object entry.

The various object parameter groups are organized in index ranges as shown below:

Screen Shot 2020-02-10 at 7.06.48 PM

Example entries for Communication Profile

Screen Shot 2020-02-10 at 7.16.52 PM

Example of sub indexes for referencing complex or structured data type entries

Screen Shot 2020-02-10 at 7.16.57 PM

The entries are for a single channel RS-232 interface, that may have its communication parameters exist as a single structured data type at index 6092H. The individual communication parameters then exist in sub indexes of 6092H, and ranges from 0.

The C programming language structure definition for above object dictionary entries is:

typedef struct{
	UNSIGNED char NumberOfEntries;

	UNSIGNED short BaudRate;

	UNSIGNED char NumberOfDataBits;

	UNSIGNED char NumberOfStopBits;

	UNSIGNED char Parity
} RS232

Network Management in CANopen

The CANopen network management uses the Master/Slave communication model. The entire network is implemented as a “state machine” in which, one device is designated as the NMT Master and other devices as NMT Slaves. The NMT master controls and monitors the states of the NMT slaves. The NMT slaves go through state transitions triggered by the NMT master to enter into various phases of CANopen network implementation. 

CANopen_State_Diagrams

The state change commands are issued from the Master to the Slave(s) for these state transitions using specific NMT protocols like the Bootup Protocol, Module Control Protocol, Heartbeat Protocol and Node Guarding. The NMT master sends NMT command codes to specific node(s) or all nodes to change state.

The initial state transition sequence of the NMT Slave state machine starts from Power-On or a recovery from Power-Off events followed by device Initialization. The NMT slave devices will then automatically make transition into the Pre-Operational state. The Internal Device Reset (Reset Application and Reset Communication) event during error control and diagnostics also will take the NMT slave devices into the Initialization state followed by the Pre-Operational state. Before this transition, the devices will transmit a boot-up message into the bus using the Boot-Up protocol to indicate the boot-up process.

In the Pre-Operational state, the application configuration tool can configure and parameterize the NMT slaves using SDO communication. Since the devices are not yet operational, no PDO communication is allowed at this state. 

Once the state is changed from Pre-Operational to Operational, all the communication objects in the nodes become active and both PDO and SDO communications are allowed between operational nodes. During this stage object dictionary access through SDO is also possible. Both PDO and SDO communication are stopped once the node state is changed to Stopped. 

Node Status Monitoring in CANopen

The NMT master regularly polls slave devices with a remote frame to retrieve their current state and matches those with the earlier states recorded in the network database. Any mismatches and absence of PDO transmission are indicated with appropriate error codes and the application will take appropriate actions like device reset or error indication. This is called Node Guarding and is implemented using the Node Guarding Protocol. NMT slaves use a technique called Life Guarding to detect the absence of NMT master by checking internally for reception of Node Guarding frames in pre-defined time intervals.

Modern device designs use the Heartbeat Protocol for node monitoring in which the NMT slave (the Heartbeat Producer) will cyclically send Heartbeat Messages to the NMT master (Heartbeat Consumer). The interval between these messages is configurable and set in the Heartbeat producer time object in object dictionaries of both devices. If the Heartbeat message does not arrive within this time limit, the producer will be considered as down and consumer takes remedial actions like device reset or error indication.

Pre-Defined Connection Set

For simple communication structures with exactly 1 master and upto 127 slaves, CANopen provides pre-defined allocation of CAN message identifiers called Pre-Defined Connection Set. The overall aim of this scheme is to reduce the configuration overhead in simple networks that need peer-to-peer connections only. This pre-defined master-slave connection scheme supports communication object allocation as follows per device:

  • One Emergency object
  • SYNC and TIMESTAMP objects
  • One SDO connection 
  • NMT for node monitoring (node guarding/heartbeat)
  • Upto 4 transmit and 4 receive PDOs

Electronic Data Sheet and CANopen System Configuration

An Electronic Data Sheet (EDS) is a standardized electronic file that describes the communication functionality and objects defined for the CANopen device. This vendor generated file has 3 areas:

  • Information about the EDS file
  • General device information 
  • Object dictionary with default values

The EDS file can be used as a tool for configuration and network setup for CANopen devices.

CANopen and Kvaser

Kvaser has developed the Kvaser CANopen Stack, a user friendly and memory efficient API for implementing high performance CANopen networks. It is fully standard compliant and has full support for CANopen master and slave functionality.

CANopen in the Industry

Vector Informatik GmbH is the developer of CANalyzer, one of the best software tools for CANopen network analysis and stimulation.

Port GmbH has developed a rich collection of CANopen tools including:

  • CANopen Design Tool for CANopen device development.
  • CANopen Master/Slave Protocol Library
  • CANopen Modules and Profiles
  • CANopen Device Monitor
  • CANopen Gateway Server

National Instruments provide a 1-Port C Series CANopen Interface Module that assist in CANopen application development.

There are numerous other CANopen commercial tools as well as open source APIs and protocol stacks like CANopenNode that leverages on the open architecture of CANopen and utilizes its highly standardized and detailed recommendations, guidelines and implementations.


More Resources