Introduction To The CANopen Protocol

Version 1.1
Application Note AN-ION-1-1100

Restrictions Public Document

Abstract This application note is a brief introduction to the Higher-Layer CAN Protocol called
CANopen.

Table of Contents

1 Overview .......................................................................................................................................................................1
1.1 History ........................................................................................................................................................................2
1.2 Highlights ...................................................................................................................................................................2
2 Standardized Structure ................................................................................................................................................2
3 The Device Model ........................................................................................................................................................4
4 Physical Layer ..............................................................................................................................................................4
5 The Object Dictionary ..................................................................................................................................................4
6 Communication Channels ...........................................................................................................................................5
7 Network Management..................................................................................................................................................6
8 Pre-Defined Connection Set........................................................................................................................................8
9 CANopen System Configuration .................................................................................................................................8
10 Device Profiles .............................................................................................................................................................9
11 Conclusion ....................................................................................................................................................................9
12 Contacts........................................................................................................................................................................9

1 Overview
CANopen is a "Layer 7" CAN protocol that defines communication and device functions for CAN-based systems.
CANopen is a standardized, highly flexible, and highly configurable embedded network architecture used in industries
such as Railway, Medical, Industrial, Agriculture, Heavy Truck & Bus, Marine, Off-Highway, Factory Automation,
Aerospace, and many others. CANopen is also becoming a popular choice for closed, company-specific embedded
networks. The CANopen profile family specifies standardized communication mechanisms and device functionalities.
The CANopen Standard is maintained by "CAN in Automation (CiA) International Users and Manufacturers Group" and
can be implemented without a license.

Copyright © 2003 - Vector Informatik GmbH. 1

Contact Information: www.vector-cantech.com or 1-248-449-9290
 Introduction To The CANopen Protocol

1.1 History
1992 (Jul) Start of ESPRIT III Project ASPIC.
CAN selected as a suitable field bus system.
Start of communication and device profile development.
1994 (Jun) Profiles handed over to the CAN in Automation (CiA) international users and manufacturers group.
1994 (Sept) First implementations outside ASPIC.
1995 (Feb) The standard is given the name "CANopen".
1995 (Apr) CANopen robot cell shown at HMI.
1995 (Oct) Communication profile DS-301 available.
1996 (Feb) First device profile (DS-401) was available.
1996 (Apr) Multi-vendor system shown at HMI.
1996 - 1997 Development begins on several device profiles and a Framework for Programmable Devices (WD-
302).
1999 (Jun) The DS-301 submitted for European Standardization.
2001 The European standardization authorities accept CANopen version 4.01 as EN 50325-4.
Present Many device profiles and frameworks are available.
Hundreds of implementations in the worldwide market.

1.2 Highlights
CANopen protocol characteristics:
• Open architecture
• Real-time transfer of process data without protocol overhead
• Modular and scalable
• Interoperability and interchangeability
• Profile concept similar to Interbus-S and Profibus
• Supported by many international manufacturers

CANopen allows:
• Standardized configuration of networks
• Access to all device parameters
• Synchronization
• Cyclic and event-driven process data transfer combined with asynchronous domain transfer

2 Standardized Structure
Compared to the ISO/OSI Stack, CANopen is a "Layer 7" communication profile based on CAN, which is standardized
in ISO 11898. It is supplemented by a set of device profiles.
The CiA manages the documents. The main document is the "CiA DS 301 - CANopen Application Layer And
Communication Profile" (EN 50325-4). It describes all basic principles, data types, encoding rules and services.

Application Note AN-ION-1-1100 2

 Introduction To The CANopen Protocol

Figure 1 – The ISO OSI Stack

The following set of papers supplement the DS-301 (there are more):
• CiA DSP-306 - CANopen electronic data sheet (EDS) for CANopen
• CiA DSP 302 - CANopen framework for CANopen managers and programmable CANopen devices
• CiA DSP 305 - CANopen layer setting services and protocol (LSS)
• CiA DR 303-1 - CANopen cabling and connector pin assignment

A series of device, application, and interface profiles complete the specification.

Figure 2 – CANopen Documents

Application Note AN-ION-1-1100 3

 Introduction To The CANopen Protocol

3 The Device Model

A unified view of CANopen devices requires the use of a general device model so that different devices can be
described by one standard. The device model consists of three main components:
• Communication
• Object Dictionary
• Application

Figure 3 – CANopen Device Model

4 Physical Layer
The physical medium for CANopen devices is a differentially driven two-wire bus line with common return according to
the ISO 11898 standard. The CANopen standard does not mandate a specific Physical Layer, which allows CANopen
to be used in specific environments. CANopen does however provide a set of recommendations and specifications for
industrial use. CiA DR 303-1 defines pin assignments for many connectors, such as the 9-pin D-sub connector (DIN
41652 or corresponding international standard), the 5-pin mini style connector, the open style connector and the multi-
pole connector.

5 The Object Dictionary

CANopen is built around the central concept of an Object Dictionary (OD), the interface between the application and
communication within each device. Every function, variable and data type seen via the network must be described in
the OD. Object Dictionary characteristics include:
• Collection of communication and application-relevant parameters
• Standardized structure
• Access to structured parameters (arrays, records)
• Reference to data types

In order to allow access to all entries, the OD defines a standard addressing scheme where each object has an index.
The index is a 16-bit offset into the OD. There is direct access to non-structured objects like Boolean, Unsigned32,
etc.

Main Index Variable Accessed Data Type

1000H Device Type Unsigned32

Table 1 – Object Dictionary Standard Addressing Scheme

From a programmer’s point of view, this is equivalent to:

Application Note AN-ION-1-1100 4

 Introduction To The CANopen Protocol

unsigned long DeviceType;

Structured data types use an 8-bit sub-index to denote a field inside a structure or array.
Main Index Sub Index Variable Accessed Data Type
6092H 0 Number Of Entries Unsigned8
1 Baud Rate Unsiged16
2 Number Of Data Bits Unsigned8
3 Number Of Stop Bits Unsigned8
4 Parity Unsigned8

Table 2 – Array And Structure Indices

From a programmer’s point of view, this is equivalent to:

typedef struct {
unsigned char NumberOfEntries;
unsigned short BaudRate;
unsigned char NumberOfDataBits;
unsigned char NumberOfStopBits;
unsigned char Parity;
} RS232;
RS232 rs232;

The indexes are organized in several index ranges:

Index (hex) Object

0000 not used
0001-025F Data Types
0260-0FFF Reserved for further use
1000-1FFF Communication Profile Area
2000-5FFF Manufacturer Specific Profile Area
6000-9FFF Standardized Device Profile Area
A000-BFFF Standardized Interface Profile Area
C000-CFFF Reserved for further use

Table 3 – Pre-defined Index Ranges

6 Communication Channels
The basic communication mechanisms are categorized as one of the following relationships:
• Client / Server - Point-to-point connection.
The client always takes the initiative (N Clients, n Servers)
• Master / Slave - Point-to-point connection.
The Master always takes the initiative (1 master, 1...127 Client Servers)
• Producer / Consumer - This broadcast connection is exactly like the CAN protocol’s broadcast capability.
The Producer takes the initiative during the unconfirmed relationship. The Consumer takes the
initiative during the confirmed relationship (N Producers, M Consumers)

The two most important communication types are the Process Data Object (PDO) and Service Data Object (SDO):

Application Note AN-ION-1-1100 5

 Introduction To The CANopen Protocol

Process Data Object PDO Service Data Object SDO

• High priority real-time data exchange • Access to object dictionary

• Broadcast • Peer-to-peer communication
• Non-acknowledged • Acknowledged service
• No protocol overhead • Low priority
• Synchronous / asynchronous, cyclic/ • Transfer of domains
acyclic, event driven transmission
• Maximum 8 bytes of data

The PDO is used for normal process data The SDO is used for configuration and
communication, the primary purpose of the diagnostic access to a device. It is not as fast
CANopen network. as PDO, but provides the most flexible means
to read/write any amount of data.

CANopen defines additional communication objects for real-time usage, such as TIME and SYNC.

7 Network Management
A CANopen network requires a Network Management (NMT) Master and all NMT Slave devices to implement a state
machine. The NMT Master controls the status of all the NMT Slaves on the network. After "power-on" and internal
initialization, the NMT Master automatically brings every Slave device into the "Pre-operational" state. Each Slave
device may be configured and parameterized via SDO (e.g., Master or configuration tool), but no PDO communication
is allowed at this state. Now the NMT Master may switch all nodes (or a single node) to their "Operational" state. In
the "Operational" state, all communication objects are active. Switching a node into a "Stopped" state terminates all
PDO and SDO communication.

Application Note AN-ION-1-1100 6

 Introduction To The CANopen Protocol

Figure 4 – NMT State Machine

CANopen has two alternatives for protecting the existence and status of the state machine: the Heartbeat and
Guarding protocols. The Heartbeat protocol is only used in modern system designs. CANopen devices have signal
error conditions, such as "Voltage low", for when an event occurs instead of having to be polled from a Master. The
Emergency (or EMCY) message contains standard and profile-specific error codes.

Figure 5 – Heartbeat

Application Note AN-ION-1-1100 7

 Introduction To The CANopen Protocol

8 Pre-Defined Connection Set

Client/Server and Producer/Consumer connections can be set-up dynamically by configuring the Object Dictionary.
Since most systems have a central application master, CANopen establishes a "Pre-defined Connection Set" to
reduce the effort in inter-connecting devices. Every CANopen "ready" device is configured with communication
settings to support the "Pre-defined Connection Set".

Figure 6 - Resulting Connections Of The Pre-Defined Connection Set

9 CANopen System Configuration

CANopen defines a means for system configuration. This is supported through standard PC file formats (Electronic
Data Sheets or EDS), non-volatile central data storage, and distributed data storage.

Figure 7 – Configuration Of CANopen Systems

Application Note AN-ION-1-1100 8

 Introduction To The CANopen Protocol

10 Device Profiles
CANopen uses the concept of device profiles. These profiles define all mandatory functionality for particular device
classes and enable standardized access to that functionality. The goals of these device profiles are:
• Define mandatory functionality and provide access to the basic functionality, for example: "set output" for I/O
or "halt" function for drives.
• Provide pre-defined communication objects and interchangeability of standard functionality, for example: "set
filter" for I/O or "feed command value" for drives.
• Unification of the device' s state machine for easier setup of networks.
• Locate vendor-specific functionality in the Object Dictionary - realization of vendor-specific features such as
"edge evaluation" for I/O
• Define additional error conditions - extension for pre-defined error codes in the DS-301 for device-specific
errors such as "short circuit on the output" for I/O

11 Conclusion
CANopen provides typical functionality required by distributed embedded communication systems. CANopen device
implementations can be tested for compliance using the CiA conformance test tool.

12 Contacts

Vector Informatik GmbH Vector CANtech, Inc. VecScan AB

Ingersheimer Straße 24
70499 Stuttgart
Germany
Tel.: +49 711-80670-0
Fax: +49 711-80670-111
Email: info@vector-informatik.de
39500 Orchard Hill Pl., Ste 550
Novi, MI 48375
Tel: (248) 449-9290
Fax: (248) 449-9704
Email: info@vector-cantech.com
Fabriksgatan 7
412 50 Göteborg
Sweden
Tel: +46 (0)31 83 40 80
Fax: +46 (0)31 83 40 99
Email: info@vecscan.com

Vector France SAS Vector Japan Co. Ltd.

168 Boulevard Camélinat
92240 Malakoff
France
Tel: +33 (0)1 42 31 40 00
Fax: +33 (0)1 42 31 40 09
Email: information@vector-france.fr
Seafort Square Center Bld. 18F
2-3-12, Higashi-shinagawa,
Shinagawa-ku, J-140-0002 Tokyo
Tel.: +81 3 5769 6970
Fax: +81 3 5769 6975
Email: info@vector-japan.co.jp

Application Note AN-ION-1-1100 9