Infoportal
Inhaltsverzeichnis
CANOpen
CanOpen is a protocol originally designed on top of the CAN bus to provide a more efficient abstraction over raw CAN.
It servers a somewhat similar purpose to TCP/UDP on top of IP, providing a standardized (and mostly manufacturer independent) mechanism for data exchange between devices including segmentation for data that would exceed the length of a single CAN message (of 8 bytes).
Terminology
| Term | Description |
| Node | Device on the network that sends and/or receives messages |
| Node ID | unique numerical identifier for a given node (each node must have one) |
| Object | A property („thing“) of a node, such as a sensory value, motor target speed or configuration data |
| Index | 16 bit number that identifies an object |
| Sub-Index | 8 bit number allowing access an object's elements (for structured data or arrays |
| Object Dictionary | a dictionary containing information for all the objects a given node supports, including its CanOpen configuration |
| PDO | „Process Data Object“, PDOs allow efficient transfer of multiple objects in a signle CAN message. CanOpen allows for a maximum of 512 PDOs per Node, however most devices will limit it to 4 (more info, see below) |
| SDO | „Service Data Object“: provides mechanism to access a node's entire object dictionary. (more info, see below) |
PDO vs SDO
PDOs
PDOs are designed for the efficient transport of cyclic data. For example, a motor drive may be configured to send the current velocity and position ever 10ms, so that a speed controller running on the computer/PLC can use a PID controller in a control loop to accurately control the position of the motor. Likewise, that computer may send out the updated target velocity and position in a PDO so that the drive can update its internal values.
This means there are 2 types of PDO: RxPDOs („Receive PDOs“) and TxPDOs („Transmit PDOs“), the difference being that a node sends TxPDOs and receives RxPDOs. Note that RX and TX are from the perspective of the node. This leads to the somewhat counter intuitive behavior of receiving TxPDOs and sending RxPDOs when using a CanOpen Master stack. To change a slave's (e.g. motor drive) control word as a PDO, that PDO needs to be configured as an RxPDO, since the drive will receive the control word we send. Likewise, to receive it's status word as a PDO, it needs to be configured as a TxPDO, since the drive will be sending it.
PDOs are designed to be sent cyclically, butt that is not a necessity. PdOs sends can be triggered by a timer (e.g. every 100ms) of „Change of State (CoS)“ Detection, where the PDO is only sent when its data changes (hence „change of state detection“). When CoS is used, an inhibit time may be configured to stop rapid data changes (and the resulting PDO transmits) to blokc other messages from getting through.
SDOs
SDOs present a less efficient but more flexible way of accessing a node's object. In contrast to PDOs, SDOs need not be configured beforehand and can be used to access a node's entire object dictionary. It is a client-server based transaction, whereby the client requests an object and the server responds to a given request. SDOs are limited to 4 bytes per message, but larger amounts of data are segmented and transmitted over multiple messages. Also, SDOs are synchronous, meaning that each transfer is accompanied by an acknowledgement from the other party.