CANopen

CANopen Introduction
CANopen is a high-level communication protocol and device profile specification that is
based on the CAN (Controller Area Network) protocol.
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 - the lines used, voltages, high-speed nature, etc.
The data link layer - 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
Application layer - how to configure, transfer and synchronize CANopen devices.
 CANopen Protocol Layer Interactions
The protocol layer interactions describe the communication on the different layers. On
the CANopen application layer the devices exchanges communication and application
objects. All these objects are accessible via a 16-bit index and '8-bit sub-index.

These communication objects (COB) are mapped to one or more CAN frames with pre-
defined or configured Identifiers. The CAN physical layer specifies the bit level including
the bit-timing.
 Important Parts of CANopen
Communication Models-There are 3 models for device/node communication:
Master/slave, client/server and producer/consumer

Communication Protocols-Protocols are used in communication, e.g. configuring nodes

(SDOs) or transmitting real-time data (PDOs)

Device States-A device supports different states. A 'master' node can change state of a
'slave' node - e.g. resetting it

Object Dictionary-Each device has an OD with entries that specify e.g. the device config.
It can be accessed via SDOs

Electronic Data Sheet-The EDS is a standard file format for OD entries - allowing e.g.
service tools to update devices
 CANopen message format
The data is transferred in frmaes of a 11-bit or 29-bit CAN-ID.
The COB-ID is communication object identifier consists of CAN-ID and control bits.
11-bit CAN-ID is split into 2 parts:
A 4-bit function code and 7-bit node ID
As such, the COB-ID details which node is sending/receiving data - and what service is
used.
 CANopen Device Model
A CANopen device can be divided into three parts:
• communication interface and protocol software
• object dictionary
• process interface and application program

The communication interface and protocol software provide services to transmit and to
receive communication objects over the bus. The object dictionary describes all data
types, communication objects and application objects used in this device. It is the
interface to the application software.
CANopen communication models
Master/Slave:-
One node acts as application master or host controller. It sends/requests data from the
slaves . There can be 0-127 slaves in standard applications.
example: NMT

Client/Server:-
A client sends a data request to a server, which replies with the requested data. Used
when an application master needs data from the OD of a slave. A read from a server is
an "upload", while a write is a "download“.
example: SDO

Consumer/Producer:-
Here, the producer node broadcasts data to the network, which is consumed by the
consumer node. The producer either sends this data on request (pull model) or without
a specific request.
example: Heartbeat
CANopen Communication Protocols
CANopen communication objects transmitted via the CAN network are described by the
services and protocols. They are classified as follows: -

The real-time data transfer is performed by the Process Data Objects (PDOs) protocol.

With Service Data Objects (SDOs) protocols the read and write access to entries of a
device object dictionary is provided.

Special Function Object protocols provide application-specific network synchronization,

time stamping and emergency message transmissions.

The Network Management (NMT) protocols provide services for network initialization,
error control and device status control.
 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.
Continue

How does the CANopen PDO service work?

For PDOs, the consumer/producer terminology is used. Thus, a producer 'produces

data', which it transmits to a 'consumer' (master) using a transmit PDO (TPDO).
Conversely, it may receive data from the consumer via a receive PDO (RPDO).
Producer nodes may e.g. be configured to respond to a SYNC trigger broadcasted by the
consumer every 100 ms. Node 5 may then e.g. broadcast below transmit PDO with COB-
ID 185:
 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.
Continue
How does it work?
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 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.
 Network Management (NMT) 
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.
Special function objects (SYNC, EMCY, TIME)

CANopen may have a SYNC producer to synchronize the actions of the CANopen nodes.
A SYNC producer issues (periodically) the SYNC object. The SYNC object has the CAN
identifier 128. This may introduce some jitter due to the priority of this message.
A device internal error may trigger an emergency (EMCY) object. The reaction of the
EMCY consumers depends on the application. The CANopen standard defines several
emergency codes. The EMCY object is transmitted in a single CAN frame with eight
bytes.
A CAN frame with the CAN ID 256 with six bytes payload can be used to transmit the
time of day to several CANopen nodes. This time stamp (TIME) object contains the
daytime value in the Time-Of-Day data type.
CANopen supports two methods of monitoring the status of devices (watchdog
mechanisms).
-A network manager may poll each device regularly in configurable time intervals. This is
called node guarding. Node guarding is, however, bandwidth consuming.

-Another mechanism is that each device regularly sends a heartbeat message. This saves
bandwidth compared to the node guarding protocol.
 CANopen Profiles
Device Profiles specify supported application objects, additional error codes, and default PDO
mappings. There are mandatory objects, optional objects and manufacturer-specific objects. Device
Profiles standardized by CIA use the Object Dictionary entries from 6000h to 9FFFh. CANopen
Application Profiles describe a specific application including all devices and optionally some
additional specifications of the physical layer.
CANopen device and application profiles.
Available profiles
CIA 401 I/O modules
CiA 402 Electric drives
CiA 404 Transducer
CIA 405 Programmable logic controllers
CiA 406 Encoders
CIA 408 Proportional valves and hydraulic transmission
CiA 410 Inclinometers
CIA 412 X-ray collimators
CiA 413 Truck gateways
CIA 414 Yarn-feeding units
CiA 415 Road construction machinery
CiA 416 Door control
CiA 417 Lift control systems
CiA 418 Battery modules
CiA 419 Battery chargers
CiA 420 Extruder downstream devices
 CANopen Object Dictionary
The object dictionary is a standardized structure containing all parameters describing the
behavior of a CANopen node.

OD entries are looked up via a 16-bit index and 8-bit subindex. For example, index 1008
(subindex 0) of a CANopen-compliant node OD contains the node device name.

Specifically, an entry in the object dictionary is defined by attributes:

•Index: 16-bit base address of the object

•Object name: Manufacturer device name
•Object code: Array, variable, or record
•Data type: E.g. VISIBLE_STRING, or UNSIGNED32 or Record Name
•Access: rw (read/write), ro (read-only), wo (write-only)
•Category: Indicates if this parameter is mandatory/optional (M/O)
 OD standardized sections
The object dictionary is split into standardized sections where some entries are
mandatory and others are fully customizable.
Importantly, OD entries of a device (e.g. a slave) can be accessed by another device (e.g.
a master) via CAN using e.g. SDOs.
CANopen Object Dictionary
CANopen Object Dictionary Regions
 The Electronic Data Sheet (EDS)
In the object dictionary the device designer indicates the supported device functionality
by implementing the related objects.

The communication behaviour is adjusted in the appropriate objects in the index range
1xxxh

Parameters and results required or generated by manufacturer specific device functions,

can be indicated in the index range 2000h to 5FFFh

In addition manufacturer specific status information and process data can be

represented to the network in that index range.
EDS is a “human readable" representation of the CANopen object dictionary
- ASCII
- XML
EDS “Architecture”
 EDS Entries
A 16-bit index is used to address all entries within the object dictionary.
- In case of a simple variable this references the value of this variable directly.

- In case of records and arrays however, the index addresses the whole data structure

- For complex object dictionary entries such as arrays or records with multiple data
fields the sub-index references fields within a data-structure pointed to by the main
index
Example: manufacture specific RS-232 interface
- Defines an entry in index 6092h to define communication parameters for that module
 Device Configuration File (DCF)
Assume a factory has bought a ServoMotor3000 to integrate into their conveyor belt. In
doing so, the operator edits the device EDS and adds specific parameter values and/or
changes the names of each object described in the EDS.
In doing so, the operator effectively creates what is known as a Device Configuration File
(DCF). With this in place, the ServoMotor3000 is ready for integration into the specific
CANopen network on-site.
Example:-