The Basics of CANopen

Updated Mar 5, 2019




Contents
 CANopen Introduction
 The Basics of the CANopen Application Layer
 NI CANopen Interfaces

CANopen Introduction
CANopen is a high-level communication protocol and device profile specification that
is based on the CAN (Controller Area Network)protocol. The protocol was developed
for embedded networking applications, such as in-vehicle networks. The CANopen
umbrella covers a network programming framework, device descriptions, interface
definitions and application profiles. CANopen provides a protocol which standardizes
communication between devices and applications from different manufacturers. It has
been used in a wide range of industries, with highlights in automation and motion
applications.

In terms of the OSI communication systems model, CAN covers the first two levels:
the physical layer and the data link layer. The physical layer defines the lines used,
voltages, high-speed nature, etc. The data link layer includes the fact that CAN is a
frame-based (messages) protocol. CANopen covers the top five layers: network
(addressing, routing), transport (end-to-end reliability), session (synchronization),
presentation (data encoded in standard way, data representation) and application. The
application layer describes how to configure, transfer and synchronize CANopen
devices. The concepts of the application layer, covered in specification CiA DS 301,
are covered in this document. The intention is to give users a brief overview of the
concepts of CANopen.
 CAN and CANopen in the OSI Model

Back to top

The Basics of the CANopen Application

Layer
The following section explains the basic concepts related to the CANopen protocol
application layer. This document is intended as a basic overview only, and users are
encouraged to review the CiA DS 301 specification for more information.

Object Dictionary

One of the central themes of CANopen is the object dictionary (OD), which is
essentially a table that stores configuration and process data. It is a requirement for all
CANopen devices to implement an object dictionary. The CANopen standard defines a
16-bit bit index and an 8-bit sub-index. That is, it is permissible to have up to 65536
indices and up to 256 subentries at each index. The standard defines that certain
addresses and address ranges must contain specific parameters. For example, the
standard defines that index 1008h, sub-index 00h, must contain the device name. As
such, any CANopen master can read this index from a network of CANopen slaves in
order to uniquely identify each slave by name.  Some object dictionary indices, such
as the device type (1000h) are mandatory, and others, such as the manufacturer
software version (100Ah) are optional. The collection of mandatory indices represents
the minimum object dictionary, which is required to brand a device CANopen
compliant.
The object dictionary is the method by which a CANopen device can be communicated
with. For example, one could write a true to the index in the manufacturer-specific
section of the object dictionary (2000h-5FFFh), which the device could interpret as an
enable signal for acquiring data from a voltage input. Conversely, the master may also
want to read information from the object dictionary to get the acquired data, or to find
out how to device is currently configured. The two communication mechanisms for
accessing the object dictionary are Service Data Objects (SDOs) and Process Data
Objects (PDOs), which will be explained later in this document.

The basic data types included in the object dictionary are: Boolean, void (placeholder),
unsigned integer, signed integer, floating point and character. More complex data
types, such as strings, date and time can be constructed from the basic data types.
These data types can be used to define custom data types specific to CANopen, such
as the PDO/SDO Parameter Record and the PDO mapping parameter. The user is
encouraged to review the CANopen specification for more details on the components
of complex and custom data types.

CANopen Message Format

The message format for a CANopen frame is based on the CAN frame format. In the
CAN protocol, the data is transferred in frames consisting of an 11-bit or 29-bit CAN-
ID, control bits such as the remote transfer bit (RTR), start bit and 4-bit data length
field, and 0 to 8 bytes of data. The COB-ID, commonly referred to in CANopen,
consists of the CAN-ID and the control bits. In CANopen, the 11-bit CAN ID is split into
two parts: a 4-bit function code and a 7-bit CANopen node ID. The 7-bit size limitation
restricts the amount of devices on a CANopen network to 127 nodes.

CANopen Frame Format (bits shown except for data field)

All COB-ID's must be unique to prevent conflicts on the bus. In SDO communication,
there should always be only one node that needs to access the individual object
dictionary indices of the slave nodes.
Service Data Objects (SDOs)

The CANopen protocol also specifies that each node on the network must implement a
server that handles read/write requests to its object dictionary. This allows for a
CANopen master to act as a client to that server. The mechanism for direct access
(read/write) to the server’s object dictionary is the Service Data Object (SDO). The
node whose object dictionary is accessed is referred to as the SDO server, and the
node grabbing the data is referred to as the SDO client. The transfer is always started
by the SDO client.

Typically, the master CANopen node will send a request to the network, and the node
of interest will respond with the data requested. CANopen uses reserved message IDs
to facilitate this communication. When the SDO client wants to request information
from the server, it sends an SDO request using a CAN-ID of 600h + Node ID. The
server will then respond using a CAN-ID of 580h + Node ID. The Node ID specifies
which slave node the message is coming from. For the example illustrated below, the
master node (the SDO client) sends a message out to the network with a CAN-ID of
603h. Although all nodes see this message, all nodes but the targeted node ignore it
because the message is not intended for them. The targeted node understands that
the message with ID 603h means that the message is intended for that node, which is
an SDO request. The data field of the message will specify the index and sub-index of
the object which the master would like to access data.  The targeted node then
responds with message ID 583h. The data field of the response message will contain
the data requested.
   

SDO Example

In addition to having a specific CAN-ID, the data section of the CANopen frame also
follows a specific format for SDO. The data section of the CAN frame is split into three
parts: one byte for the specifier, three bytes for the node index and subindex, and four
bytes for the actual data in the transfer. The specifier byte is broken out in the diagram
shown above. The three bits of the specifier byte are referred to as the client
command specifier (ccs), which indicates what type of message is being transferred
(i.e. read, write, and abort). The fourth bit is reserved. The fifth and sixth bits indicate
the number of bytes in the data part of the message that do not contain actual data.
The seventh bit indicates whether the transfer is an expedited transfer or a segmented
transfer. The final bit indicates whether the amount of data is specified in bit five/six or
whether it is specified in the data part of the message.
 SDO Frame - Data Section Detail

A segmented transfer is selected when all the data that needs to be transferred does
not fit into a single message, and therefore the data must be transferred using multiple
messages or "segments". On the contrary, an expedited transfer is where all data is
sent as a single message. In the initialization phase (see NMT section), SDOs can
transfer up to four bytes of data. Optionally, an SDO transfer can also occur in a series
of blocks. Each block consists of up to 127 segments. A block transfer is faster than a
segmented transfer for large data sets.

Process Data Objects (PDOs)

Process data represents data that can be changing in time, such as the inputs (i.e.
sensors) and outputs (i.e. motor drives) of the node controller. Process data is also
stored in the object dictionary. However, since SDO communication only allows
access to one object dictionary index at a time, there can be a lot of overhead for
accessing continually changing data. In addition, the CANopen protocol has the
requirement that a node must be able to send its own data, without needing to be
polled by the CANopen master. Thus, a different method is used to transfer process
data, using a communication method called Process Data Objects (PDOs). 

There are two types of PDOs: transfer PDOs (TPDOs) and receive PDOs (RPDOs). A
TPDO is the data coming from the node (produced) and a RPDO is the data coming to
the node (consumed). In addition, there are two types of parameters for a PDO: the
configuration parameters and the mapping parameters. The section of the object
dictionary reserved for PDO configuration and mapping information are indices 1400h-
1BFFh.

The configuration parameters specify the COB-ID, the transmission type, inhibit time
(TPDO only) and the event timer, which are explained in this section. There are
different methods through which a PDO transfer can be initiated. These methods
include event driven, time driven, individual polling and synchronized polling. The type
of transmission is specified in the configuration parameters of the PDO. In event driven
transmission, the PDO transfer is initiated when the process data in it changes. In time
driven transmission, the PDO transfer occurs at a fixed time interval. In individual
polling, the PDO transfer is initiated using a mechanism called remote request, which
is not commonly used. In synchronized polling, the PDO transfer is initiated using a
SYNC signal. The sync signal is frequently used as a global timer. For example, if the
CANopen master sends out a SYNC message, multiple nodes may be configured to
see and respond to that SYNC. In this way, the master is able to get a "snapshot" of
multiple process objects at the same time.

Event Driven PDOs Transfer Example

The mapping parameters specify which object dictionary values are sent by a single
PDO message. For example, a single PDO message may contain data from object
index 2001h, 2003h and 2005h.

TPDO Object Dictionary Example

Network Management (NMT) Overview

Network management services include the ability to change the state of a slave
between initializing, pre-operational, operational and stopped. The NMT protocol
allows for the CANopen network to control the communication state of individual
nodes. The pre-operational state is mainly used to for the configuration of CANopen
devices. As such, PDO communication is not permitted in the pre-operational state.
PDO communication becomes possible in the operational state. In the stopped state, a
node can only do node guarding or heartbeats, but cannot receive or transmit
messages. Certain types of CANopen communication are allowed in different states.
For example, SDOs are allowed in the preoperational state, but PDOs are not. This is
because SDOs are often used to initialize object dictionary parameters, whereas
PDOs are often used to transfer continually updating data.

Guarding and Heartbeats

The CANopen specification requires that nodes must use some method to check
whether a node is "alive" or not. The two methods available are: node guarding and
heartbeats, with the latter being the preferred method.

In the heartbeat protocol, a CANopen node periodically sends out a heartbeat

message which lets the CANopen master or the heartbeat consumer, know that the
node is still alive. If a heartbeat message does not arrive within a certain period of
time, the master can take a specific action. Such an action might be to reset the node
or to report an error to an operator. The heartbeat message is identified by a CAN-ID
of 0x700 + the node ID, where the first data byte is equal to 1110.

In the node guarding protocol, the CANopen master polls the slave nodes for their
current state information. If the node does not respond in a specific period of time, the
master assumes the node is dead and will take an action.

The heartbeat protocol is the preferred method because it has less overhead than
node guarding.

Emergency Messages

Each node in a CANopen network is assigned a single emergency (EMCY) message

that communicates the node's status. Note that the heartbeats and node guarding
protocol are intended to be used to convey communication failures, whereas
emergency messages are used to convey errors within the node (i.e. sensor failure).
An EMCY message is identified by a COB-ID of 80h + Node ID. The data portion of an
EMCY message contains information about the error that occurred.

Back to top

NI CANopen Interfaces
National Instruments offers CANopen master interfaces for CompactRIO, PXI, and PCI
form factors. Each interface is supported by the Industrial Communications for
CANopen driver, which features support for SDOs, PDOs, NMT, heartbeats, node
guarding and synchronization. The driver also features a Batch SDO editor, which
allows a user to easily configure the nodes on the CANopen network. The Batch SDO
Editor has support for EDS file integration and LSS services support for slave node
configuration.

NI-9881: 1-Port CANopen Module for NI CompactRIO

The NI 9881 is a 1-port, high-speed CANopen C Series module interface for
developing CANopen applications in NI LabVIEW software on
NI CompactRIO hardware. The NI-9881 is externally powered and can attain transfer
rates of up to 1Mbit/s. The CANopen port is accessible from the CompactRIO Real-
Time controller. The 9881 module requires the NI cRIO-911x chassis and
the LabVIEW FPGA Module.

NI-9881
See Also
NI 9881 1-Port CANopen Module for NI CompactRIO Product
Page

NI PCI/PXI-8531: 1-Port CANopen Interface for PCI/PXI

The NI PCI-8531 and NI PXI-8531 are both 1-Port CANopen Interfaces for the PCI
and PXI platforms, respectively. They feature transfer rates of up to 1 Mbit/s, and
leverage the Industrial Communication for CANopen Driver.
NI PXI-8531