Design Article

IMG1

CANopen: An Introduction

Konrad Etschberger

5/13/2003 12:00 AM EDT

The profile family CANopen defines a standardized application for distributed industrial automation systems based on CAN. CANopen was developed by CAN-in-Automation (CiA) and is standardized by CENELEC EN 50325-4. Soon after its release, it found a broad acceptance, especially in Europe where CANopen is considered the dominating standard for CAN-based industrial and embedded system solutions.

The CANopen profile family is based on a "Communication Profile", which specifies the basic communication mechanisms and on a standardized form for describing the functionality of devices.

The most important device types such as digital and analog I/O modules, drives, operating devices, sensors, or programmable controllers are described by so-called "Device Profiles". In the device profiles the functionality, parameters, and data of standard devices of the corresponding types are specified. Based on the standardized profiles devices of different manufacturers can be accessed via the bus in exactly the same manner. Therefore devices of different manufacturers are interoperable and exchangeable.

The key element of the CANopen standard is the description of the device functionality by means of an "Object Dictionary" (OD). The object dictionary is divided into two sections. The first section contains general device information such as device identification, manufacturer name, and so on, as well as communication parameters. The second section describes the specific device functionality.

A 16-bit index and an 8-bit sub-index identify an entry ("object") in the object dictionary. The entries in the object dictionary provide the standardized access to the "Application Objects" of a device, such as input and output signals, device parameters, device functions, or network variables.

You can describe the functionality and characteristics of a CANopen device by means of an "Electronic Data Sheet" (EDS) using an ASCII-format. An EDS must be understood as a kind of template for describing all the data and features of device as accessible from the network. The actual device settings are described by the so-called "Device Configuration File" (DCF). EDS and DCF can be provided in the form of a data file, which can be downloaded from the Internet or stored inside the device. Similar to other field bus systems CANopen distinguishes two basic data transmission mechanisms:

  • The access to entries of the object dictionary through "Service Data Objects" (SDO)

  • The exchange of process data through "Process Data Objects" (PDOs).

Process data objects are transmitted according to the producer-consumer principle in form of broadcast messages and can be event-triggered, cyclically transmitted, or requested by a node without any additional protocol overhead. A PDO can be used for the transmission of a maximum of 8 data bytes. In connection with a synchronization message ("Synchronous PDO"), the transmission as well as the acceptance of PDOs can be synchronized across the network. The mapping of application objects into the data field of a PDO is configurable through a data structure called "PDO Mapping" which is stored in the object dictionary. This allows the dynamic configuration of a device according to the specific requirements of an application.

The transmission of data via an SDO channel is performed in form of a client-server relationship between two nodes. The addressing of an object dictionary entries is accomplished by providing the index and the sub-index of the entry. Transmitted messages can be of very large length. The transmission of SDO messages of more than 8 bytes involves an additional fragmentation protocol overhead.

Standardized event-triggered "Emergency Messages" of high priority are reserved to report device malfunctions. A common system time can be provided through a system time message.

 
For more information about CAN, CANopen, DeviceNet, and SAE J1939 please refer to the author's book:

Etschberger: "Controller Area Network. Basics, Protocols, Chips and Applications". 2001, IXXAT.
ISBN 3-00-007376-0. Available via Amazon or IXXAT
 
Network management functions like controlling and monitoring the communication status of the nodes are accomplished by a network management facility. This is organized according to a logical master-slave relationship. Two mechanism for node monitoring ("node-guarding" and "heartbeat-messaging") are provided alternatively.

The assignment of CAN message identifiers to PDOs and SDOs is possible by direct modifications of identifiers in the data structure of the object dictionary or, for simple system structures, through the use of pre-defined identifiers.

Besides device profiles, today also a variety of application specific profiles developed by several specific interest groups are available and a wide variety of manufacturers support CANopen by means of CANopen-based devices, tools for configuration, and testing as well as certified CANopen protocol stacks.


About the Author
Prof. Dr.-Ing. K. Etschberger teaches "Real-Time-Systems" and "Industial Communication" at the University of Applied Sciences in Weingarten, Germany. He has been involved in the design, development, and implementation of CAN technology since 1989. In 1994 he published his first book about CAN.

In 1987 he founded stzp, a technology transfer company which was one the first CAN pioneers in Germany. In 1980 the activites of stzp were transferred to IXXAT Automation, Weingarten, today a leading provider of CAN-based products, system designs, and solutions.

For more information on CAN and CANopen, visit IXXAT Automation's Web site.


print

email

rss

Bookmark and Share

Joinpost comment




Please sign in to post comment

Navigate to related information

Product Parts Search

Enter part number or keyword
PartsSearch

FeedbackForm