The Basics of CANopen

Publish Date: Aug 21, 2013

Table of Contents

1. CANopen Introduction
2. The Basics of the CANopen Application Layer
3. NI CANopen Interfaces
1. CANopen Introduction

CANopen is a high-level communication protocol and device profile specification that is based on the CAN (Controller Area
Network) (http://www.ni.com/white-paper/2732/en)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 moti
applications.

In terms of the OSI communication systems model, CAN covers the first two levels: the physical layer and the data link layer. T
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 (http://www.can-cia.org/index.php?id=downloads), 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

2. 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
a basic overview only, and users are encouraged to review the CiA DS 301 specification (
http://www.can-cia.org/index.php?id=downloads) 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, suc
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 compli

The object dictionary is the method by which a CANopen device can be communicated with. For example, one could write a tru
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 la
in this document.

The basic data types included in the object dictionary are: Boolean, void (placeholder), unsigned integer, signed integer, floatin
1/7

www.ni.com

The basic data types included in the object dictionary are: Boolean, void (placeholder), unsigned integer, signed integer, floatin
point and character. More complex data types, such as strings, date and time can be constructed from the basic data types. Th
data types can be used to define custom data types specific to CANopen, such as the PDO/SDO Parameter Record and the PD
mapping parameter. The user is encouraged to review the CANopen specification for more details on the components of compl
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 tha
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
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 servers object dictionary is the Service Data Object (SDO). The node whose object dictionary is accessed i
referred to as the SDO server, and the node grabbing the data is referred to as the SDO client. The transfer is always started b
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 th
message, all nodes but the targeted node ignore it because the message is not intended for them. The targeted node understa
that the message with ID 603h means that the message is intended for that node, which is an SDO request. The data field of th
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.

2/7

www.ni.com

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 fo
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 (
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
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 therefor
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,
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)

3/7

www.ni.com

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 th
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 Da
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:
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 ar
explained in this section. There are different methods through which a PDO transfer can be initiated. These methods include ev
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 "snapsho
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.

4/7

www.ni.com

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, operationa
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
the pre-operational state. PDO communication becomes possible in the operational state. In the stopped state, a node can only
node guarding or heartbeats, but cannot receive or transmit messages. Certain types of CANopen communication are allowed
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 no
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. Not
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.
3. NI CANopen Interfaces

National Instruments offers CANopen master interfaces for CompactRIO (http://www.ni.com/compactrio), PXI, and PCI form
factors. Each interface is supported by the Industrial Communications for CANopen (
http://joule.ni.com/nidu/cds/view/p/id/3077/lang/en) 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 o
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 (http://www.ni.com/compactrio) hardware. The NI-9881 is externally powered and can attain transf
rates of up to 1Mbit/s. The CANopen port is accessible from the CompactRIO Real-Time controller. The 9881 module requires
NI cRIO-911x chassis and the LabVIEW FPGA (http://www.ni.com/fpga) Module.

5/7

www.ni.com

NI-9881
See Also
NI 9881 1-Port CANopen Module for NI CompactRIO Product Page (http://sine.ni.com/nips/cds/view/p/lang/en/nid/209998)
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 featur
transfer rates of up to 1 Mbit/s, and leverage the Industrial Communication for CANopen Driver.

NI PXI-8531

See Also
NI PCI-8531 1-Port CANopen Interface for PCI Product Page (http://sine.ni.com/nips/cds/view/p/lang/en/nid/209996)
NI PXI-8531 1-Port CANopen Interface for PXI Product Page (http://sine.ni.com/nips/cds/view/p/lang/en/nid/209997)
Related Links
National Instruments CANopen Interfaces Home Page (http://sine.ni.com/nips/cds/view/p/lang/en/nid/209981)
KnowledgeBase 5W8COLVO: Summary of CANopen Software Availability and Compatibility with National Instruments Product
http://digital.ni.com/public.nsf/allkb/13C3CB1148A2AEA4862579DB0066E66B)

PRODUCT

SUPPORT

COMPANY

Order status and history (http://www.ni.com/status/) Submit a service request (

https://sine.ni.com/srm/app/myServiceRequests)
Order by part number (
http://sine.ni.com/apps/utf8/nios.store?action=purchase_form
Manuals (http://www.ni.com/manuals/)
)
Drivers (http://www.ni.com/downloads/drivers/)
Activate a product (
http://sine.ni.com/myproducts/app/main.xhtml?lang=en
Alliance Partners (http://www.ni.com/alliance/)
)

About National Instruments (

http://www.ni.com/company/)
Events (http://www.ni.com/events/)
Careers (http://www.ni.com/careers/)

Order and payment information (

http://www.ni.com/how-to-buy/)

MISSION
NI equips engineers and scientists with systems
that accelerate productivity, innovation, and
discovery.

6/7

www.ni.com

(http://twitter.com/niglobal)

http://www.facebook.com/NationalInstruments)
(
http://www.linkedin.com/company/3433?trk=tyah)
(http://www.ni.com/rss/)

http://www.youtube.com/nationalinstruments)
Contact Us (http://www.ni.com/contact-us/)

(http://privacy.truste.com/privacy-seal/National-Instruments-Corporation/validation?rid=bc6daa8f-7051-4eea-b7b5-fb24dcd96d95)
Legal (http://www.ni.com/legal/) | National Instruments. All rights reserved. | Site map (
http://www.ni.com/help/map.htm)

7/7

www.ni.com