CANopen
From Wikipedia, the free encyclopedia
CANopen is a communication protocol and device profile specification for embedded systems used in automation. In terms of the OSI model, CANopen implements the layers above and including the network layer. The CANopen standard consists of an addressing scheme, several small communication protocols and an application layer defined by a device profile. The communication protocols have support for network management, device monitoring and communication between nodes, including a simple transport layer for message segmentation/desegmentation. The lower level protocol implementing the data link and physical layers is usually Controller Area Network (CAN), although devices using some other means of communication (such as EtherCAT) can also implement the CANopen device profile.
The basic CANopen device and communication profiles are given in the CAN in Automation (CiA) draft standard 301. Profiles for more specialized devices are built on top of this basic profile, and are specified in numerous other standards released by CAN in Automation, such as CiA401 for I/O-modules and CiA402 for motion control.
Contents |
[edit] Device model
Every CANopen device has to implement certain standard features in its controlling software.
- A Communication unit implements the protocols for messaging with the other nodes in the network
- Starting and resetting the device is controlled via a state machine. It must contain the states Initialisation, Pre-operational, Operational and Stopped. The transitions between states are made by issuing a network management (NMT) communication objects to the device.
- The object dictionary is an array of variables with a 16-bit index. Additionally, each variable can have an 8-bit subindex. The variables can be used to configure the device and reflect its environment, i.e. contain measurement data.
- The application part of the device actually performs the desired function of the device, after the state machine is set to the operational state. The application is configured by variables in the object directory and the data are sent and received through the communication layer.
[edit] Object dictionary
CANopen devices must have an object dictionary, which is used for configuration and non-realtime communication with the device. An entry in the object dictionary is defined by:
- Index, the 16-bit address of the object in the dictionary
- Object name, a symbolic type of the object in the entry, such an array, record, or simple variable
- Name, a string describing the entry
- Type, gives the datatype of the variable
- Attribute, which gives information on the access rights for this entry, this can be read/write, read-only, write-only or read only constant
- The Mandatory/Optional field defines whether a device conforming to the device specification has to implement this object or not
The basic datatypes for object dictionary values such as booleans, integers and floats are defined in the standard, as well as composite datatypes such as arrays, records and strings. The composite datatypes can be subindexed with an 8-bit index. The value in subindex 0 of an array or record indicates the number of elements in the data structure, and is of type UNSIGNED8.
For example, the device communication parameters, standardized in the basic device profile DS301 are mapped in the index range 0x1000 - 0x1FFFF ("communication profile area"). The first few entries in this area are as follows:
| Index | Object name | Name | Type | Attribute | M/O |
|---|---|---|---|---|---|
| 0x1000 | VAR | device type | UNSIGNED32 | ro | M |
| 0x1001 | VAR | error register | UNSIGNED8 | ro | M |
| ... | |||||
| 0x1008 | VAR | manufacturer device name | Vis-String | const | O |
| ... |
Given suitable tools, the object dictionary a the device can be configured by editing an electronic data sheet (EDS) file and uploading the variable values to the device. The format of the EDS-file is usually INI file.
[edit] Communication
[edit] Communication objects
CANbus, the physical layer of CANopen, can only transmit short packages consisting of an 11-bit id, remote transmission request (RTR) bit and a 0 to 8 bytes of data. The CANopen standard divides the 11-bit CAN frame id into a 4-bit function code and 7-bit CANopen node id. This limits the number of devices in a CANopen network to 127. An extension to the CANbus standard (CAN 2.0 B) allows extended frame ids of 29 bits, but in practice CANopen networks big enough to need the extended id range are rarely seen.
In CANopen the 11-bit id of a CAN-frame is known as communication object identifier, or COB-ID. In case of a transmission collision, the bus arbitration used in the CANbus allows the frame with the smallest id to be transmitted first and without a delay. Since in CANopen frames the first 4 bits of the frame id are reserved to the function code, giving a low code number for time critical functions ensures the lowest possible delay.
Contents of a standard CANopen frame:
| Function code | Node ID | RTR | Data length | Data | |
|---|---|---|---|---|---|
| Length | 4 bits | 7 bits | 1 bit | 4 bits | 0-8 bytes |
The standard reserves certain COB-IDs to network management and SDO transfers. Some function codes and COB-IDs have to be mapped to standard functionality after device initialiation, but can be configured for other uses later.
[edit] Communication models
Different kinds of communication models are used in the messaging between CANopen nodes.
In a master/slave relationship, one CANopen node is designated as the master, which sends or requests data from the slaves. The NMT protocol is an example of a master/slave communication model.
A client/server relationship is implemented in the SDO protocol, where the SDO client sends data (the object directory index and subindex) to an SDO server, which replies with one or more SDO packages containing the requested data (the contents of the object directory at the given index).
A producer/consumer model is used in the Heartbeat and Node Guarding protocols. In the push-model of producer/consumer, the producer sends data to the consumer without a specific request, whereas in the pull model, the consumer has to request the data from the producer.
[edit] Protocols
[edit] Network management (NMT) protocols
The NMT protocols are used to issue state machine change commands (ie. to start and stop the devices), detect remote device bootups and error conditions.
The Module control protocol is used by the NMT master to change the state of the devices. The CAN-frame COB-ID of this protocol is always 0, meaning that it has a function code 0 and node id 0, which means that every node in the network will process this message. The actual node id, to which the command is meant to, is given in the data part of the message. This can also be 0, meaning that all the devices in the bus should go to the indicated state.
The Heartbeat protocol is used to monitor the nodes in the network and verify that they are alive. A heartbeat producer (usually a slave device) periodically sends a message with binary function code of 1110 and its node id (COB ID = 1792 + node id). The data part of the frame contains a byte indicating the node status. The heartbeat consumer reads these messages. If the messages fail to arrive within a certain time limit (defined in the object directory of the devices) the consumer can take action to, for example, reset the device or indicate an error.
CANopen devices are required to make the transition from the state Initializing to Pre-operational automatically during bootup. When this transition is made, a single heartbeat message is sent to the bus. This is the bootup protocol.
A response/reply-style (pull model) protocol for slave monitoring called Node guarding protocol exists, but it is deprecated by the heartbeat protocol.
[edit] Service Data Object (SDO) protocol
The SDO protocol is used to set and read values from the object directory of a remote device. The device whose object directory is accessed is the SDO server and the device accessing the remote device is the SDO client. The communication is always initiated by the SDO client. In CANopen terminology, communication is viewed from the SDO server, so that a read from an object directory results in an SDO upload and a write to directory is an SDO download.
As the object directory values can be larger than the 8 byte limit of a CAN frame, the SDO protocol implements segmentation and desegmentation of longer messages. Actually, there are two of these protocols: SDO download/upload and SDO Block download/upload. The SDO block transfer is a newer addition to standard, which allows large amounts of data to be transferred with slightly less protocol overhead.
The COB IDs of the respective SDO transfer messages from client to server and server to client can be set in the object directory. Up to 127 SDO servers can be set up in the object directory addresses 0x1200 - 0x127F. Similarly, the SDO client connections of the device can be configured with variables at 0x1280 - 0x12FF. However the pre-defined connection set defines an SDO channel which can be used even just after bootup (in the Pre-operational state) to configure the device. The COB IDs of this channel are 0x600 + node id for receiving and 0x580 + node id for transmitting.
To initiate a download, the SDO client sends the following data in a CAN message with the 'receive' COB ID of the SDO channel:
| 3 bits | 1 bit | 2 bits | 1 bit | 1 bit | 2 bytes | 1 byte | 4 bytes |
|---|---|---|---|---|---|---|---|
| css=1 | reserved(=0) | n | e | s | index | subindex | data |
- css is the client command specifier of the SDO transfer, this is 0 for SDO segment download, 1 for initiating download, 2 for initiating upload, 3 for SDO segment upload and 4 for aborting an SDO transfer
- n is the number of of bytes in the data part of the message which do not contain data, only valid if e and s are set
- e, if set, indicates an expedited transfer
- s, if set, indicates that the date set size is specified in n (if e is set) or in the data part of the message
- index is the object directory index of the data to be accessed
- subindex is the subindex of the object directory variable
- data contains the data to be uploaded in the case of an expedited transfer (e is set), or the size of the data to be uploaded (s is set, e is not set)
[edit] Process Data Object (PDO) protocol
Process Data Object protocol is use to process real time data amoung various nodes.
[edit] Synchronization Object (SYNC) protocol
[edit] Time Stamp Object (TIME) protocol
[edit] Emergency Object (EMCY) protocol
[edit] Initialization
Sample trace of communications between a master and 2 pressure transducer slaves configured for id 1 and node id 2.
| CAN ID | DATA LENGTH | DATA | Description |
|---|---|---|---|
| 0x0 | 2 | 1 0 | Master puts bus into operational mode |
| 0x80 | 0 | Master sends a SYNC message, which triggers devices to send data | |
| 0x181 | 4 | CD 82 01 00 | Node at ID 1 (CID-0x180), reading pressure of 0x0182CD(99021) Pascals |
| 0x182 | 4 | E5 83 01 00 | Node at ID 2 (CID-0x180), reading pressure of 0x0183E5(99301) Pascals |
[edit] Glossary of CANopen Terms
PDO Process Data Object - Inputs and outputs. Values of type RPM, V, Hz, mAmps etc.
SDO Service Data Object - Configuration settings, possibly NODE ID, baud rate, offset, gain etc.
COB-ID - CAN Object Identifiers
CAN ID - CAN Identifier. This is the 11 bit CAN message identifier which is at the beginning of every CAN message on the bus.
EDS - Electronic data sheet. This is an INI style formatted file.
DCF - Device configuration file. This is modified EDS with settings for node ID and baud rate.
The EDS file is a file format, that describes the communication behaviour and the object dictionary entries of a device. Those EDS files are mandatory for passing the CiA CANopen Conformance Test. A free EDS checker is CANchkEDS
[edit] References
- ↑ CiA Draft Standard 301, available from CAN in Automation
- ↑ CiA Draft Standard 401
- ↑ CiA Draft Standard 402
