Introduction To The CANopen Protocol
Version 1.1
Application Note AN-ION-1-1100
Restrictions
Abstract
Public Document
This application note is a brief introduction to the Higher-Layer CAN Protocol called
CANopen.
Table of Contents
1
1.1
1.2
2
3
4
5
6
7
8
9
10
11
12
1
Overview .......................................................................................................................................................................1
History ........................................................................................................................................................................2
Highlights ...................................................................................................................................................................2
Standardized Structure ................................................................................................................................................2
The Device Model ........................................................................................................................................................4
Physical Layer ..............................................................................................................................................................4
The Object Dictionary ..................................................................................................................................................4
Communication Channels ...........................................................................................................................................5
Network Management..................................................................................................................................................6
Pre-Defined Connection Set........................................................................................................................................8
CANopen System Configuration .................................................................................................................................8
Device Profiles .............................................................................................................................................................9
Conclusion ....................................................................................................................................................................9
Contacts........................................................................................................................................................................9
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.
Contact Information: www.vector-cantech.com or 1-248-449-9290
1
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 (WD302).
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:
•
•
•
•
2
Standardized configuration of networks
Access to all device parameters
Synchronization
Cyclic and event-driven process data transfer combined with asynchronous domain transfer
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 multipole 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
1000H
Variable Accessed
Device Type
Data 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
6092H
Sub Index
0
1
2
3
4
Variable Accessed
Number Of Entries
Baud Rate
Number Of Data Bits
Number Of Stop Bits
Parity
Data Type
Unsigned8
Unsiged16
Unsigned8
Unsigned8
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
0001-025F
0260-0FFF
1000-1FFF
2000-5FFF
6000-9FFF
A000-BFFF
C000-CFFF
not used
Data Types
Reserved for further use
Communication Profile Area
Manufacturer Specific Profile Area
Standardized Device Profile Area
Standardized Interface Profile Area
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
•
•
•
•
•
•
High priority real-time data exchange
Broadcast
Non-acknowledged
No protocol overhead
Synchronous / asynchronous, cyclic/
acyclic, event driven transmission
Maximum 8 bytes of data
The PDO is used for normal process data
communication, the primary purpose of the
CANopen network.
Service Data Object SDO
•
•
•
•
•
Access to object dictionary
Peer-to-peer communication
Acknowledged service
Low priority
Transfer of domains
The SDO is used for configuration and
diagnostic access to a device. It is not as fast
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
Ingersheimer Straße 24
70499 Stuttgart
Germany
Tel.: +49 711-80670-0
Fax: +49 711-80670-111
Email: [email protected]
Vector CANtech, Inc.
39500 Orchard Hill Pl., Ste 550
Novi, MI 48375
Tel: (248) 449-9290
Fax: (248) 449-9704
Email: [email protected]
Vector France SAS
168 Boulevard Camélinat
92240 Malakoff
France
Tel: +33 (0)1 42 31 40 00
Fax: +33 (0)1 42 31 40 09
Email: [email protected]
Vector Japan Co. Ltd.
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: [email protected]
Application Note AN-ION-1-1100
VecScan AB
Fabriksgatan 7
412 50 Göteborg
Sweden
Tel: +46 (0)31 83 40 80
Fax: +46 (0)31 83 40 99
Email: [email protected]
9