|
|
CANopen Basics - Communication |
Object Dictionary (OD) and Electronic Data Sheet (EDS) |
One of the most important properties of CANopen is a standardized device description called object dictionary.
It is a table which has the same structure for all types of devices. Thus it is possible to access all important
data, parameters and functions of a device using a logical addressing system (index, subindex) from the "outside",
i.e. via the CAN bus.
CANopen
Bus |
 |
 |
Communication
Interface
| Server SDOs |
| Client PDOs |
| Receive PDOs |
| Transmit PDOs |
| NMT, SYNC, Emergency, Time Stamp, Heartbeat |
|
|
Object
Dictionary
| Logical addressing scheme for accessing both communication and application parameters, as well as data and functions |
|
|
Application
Process
Device functionality
- Functions
- Data
- Parameters
|
|
|
I/O
Signals
and
Process Data |
In addition to the standardized description of the communication properties of devices according to CiA 301, CANopen defines so-called
"device profiles" for typical devices of distinctive application areas. These specify the most important parameters, data and functions
per device type (e.g. input/output modules, drives, encoders, etc).
The electronical data sheet (EDS) contains data type and function of each entry of the directory. Typically, the EDS was an ASCII file,
containing all data. To allow for a more flexible and extensible handling of the data, the format was changed to XML.
|
Data Transfer via SDO and PDO |
Basically, there are two different ways to transfer data. The service data objects (SDO) bases on a client
server communication and allows for direct addressing of an object using its index and subindex. It is used
for configuration of a device, and up- and download of larger data blocks, but requires an additional protocol
overhead.
Process data Objects (PDO) provide an efficient transmission of data according to a producer-consumer model.
The datalength is limited to eight byte but does not contain any protocol overhead. One PDO can contain the
values of more than one entry of the object dictionary, but the contents of a PDO have to be defined during
initialization. Each device can specify up to 512 receive and transmit PDOs within the limitations of the
system (memory, processing power) or the network (number of available CAN identifiers).
| CAN-ID PDO2 |
Data 1
Speed |
Data 2
Position |
Data 3
Target ? |
|
|
Byte
0 |
|
Byte
2 |
|
Byte
4 |
|
Byte
6 |
Byte
7 |
|
| CAN-ID PDO3 |
Data 1
Temperature |
Data 2
Voltage |
Data 2
Current |
Data 3
Target ? |
|
A PDO is driven either by remote requests, by an internal event such as a trigger resp. a timer, or when a (cyclic)
synchronous transmission message (SYNC) is coming in. All nodes in the network are able to receive the message (PDO-Consumers).
By filtering the CAN-ID only objects of interest can be selected for further processing.
|
Emergency Messages |
As CANopen is not a hierarchical master-slave system, and node monitoring only conveys the communication
state and not the actual node status, every node requires a high priority CAN identifier to indicate error
situations. This mechanism is referred to as "Emergency Messaging" and the associated communication object
"Emergency Message". Such an emergency message consists of eight data bytes in the following form:
Error
Code |
Error
Register |
Vendor specific error field |
|
The error codes are specified in DS-301. Simultaneously with transmission of the emergency message, the device
writes the error code to its error history. The error register is content of the OD entry with bit-wise coding of the error cause.
|
 | |
|
CANopen Basics