Pages
CanOpen is built on top of the standard CAN protocol and is used extensively in Automation. It is a well defined standard and controlled by the CiA group in the words of the CiA group “CANopen unburdens the developer from dealing with CAN hardware-specific details such as bit timing and acceptance filtering. It provides standardized communication objects (COB) for time-critical processes, configuration as well as network management data.”
CanOpen splits the network up into individual nodes and each node has multiple functions, the combination of a node ID and a function produce what is known as a COB ID. In theory CanOpen supports up to 127 individual nodes. Everything in CanOpen essentially revolves around the object dictionary, every node has its own object dictionary and this contains all the data that will be transmitted between nodes, it also contains all the configuration and settings parameters of each node. There are a certain number of standard entries that all nodes are expected to have (as defined in the standard) but then there are many optional nodes that are only present if a device implements a certain function, eg a 8 output relay module has a specific entry in dictionary for setting the output states of each channel.
CanOpen much like Can is a broadcast protocol. A particular node sends a command, the command is received by all nodes. Acceptance filters within the nodes determine if the node cares about a packet or not. Most functions combine a function ID with a node ID to produce the COB ID, the standard functions are discussed next.
Standard functions
The standard functions in CanOpen are as follows:-
| ID | Description |
|---|---|
| 0x000 | NMT |
| 0x080 | Sync |
| 0x080 + Node ID | Emergency |
| 0x100 | Timestamp |
| 0x180 + Node ID | TX PDO 1 |
| 0x200 + Node ID | RX PDO 1 |
| 0x280 + Node ID | TX PDO 2 |
| 0x300 + Node ID | RX PDO 2 |
| 0x380 + Node ID | TX PDO 3 |
| 0x400 + Node ID | RX PDO 3 |
| 0x480 + Node ID | TX PDO 4 |
| 0x500 + Node ID | RX PDO 4 |
| 0x580 + Node ID | TX SDO |
| 0x600 + Node ID | RX SDO |
| 0x700 + Node ID | Guard |
| 0x7E4 | LSS TX |
| 0x7E4 | LSS RX |
The various functions listed above are described below in summary. Full details are provided on separate pages.
NMT
Network management, This packet is sent only my the master node and is used to start,stop and reset nodes on the network. Nodes have various operation states and in each state they are allowed to do certain operations.
Sync
This packet is used in combination with synchronous PDOs, the master sends the sync packet and all the slaves will respond by sending in their PDO data (that is configured as syncronous)
Emergency
This packet sends network and node critical events to all other nodes.
PDO – Process Data Objects
This protocol is used to rapidly send data from one node to 1 or more others. PDOs are very flexible and transmit particular values from one nodes object dictionary to another. The values they transmit, the update rates and behaviour are fully programmable and are themselves defined in the object dictionary,
SDO – Service Data Objects
This protocol allows you to read or write another nodes object dictionary in a polled manner. Two forms exist, a short form for expedited reads or writes where everything required fits within the 8 bytes of the CAN frame, or extended where multiple handshakes are used to transfer all the data.
Guard
This protocol is used for various guarding/heartbeat systems to ensure nodes are alive and responding. Wake up messages (when a node first powers up) also are transmitted in this protocol.
CanOpen Packets
All CanOpen packets have the same structure,
| COB-ID | RTR | Data length | data | |
|---|---|---|---|---|
| Length | 11 Bits | 1 bit | 4 bits | 0-8 bytes |
| Range | 0x000-0x7FFF | 0,1 | 0-8 | 8 Bytes |
As discussed COB ID is function + node id, it has to fit in to the 11
bit can header so values 0x000-0x7FF are allowed, lower COB-IDs have
higher priority, so NMT and emergency messages are more important than
PDOs and SDOs etc.
Next 1 bit is RTR, remote transmission request (RTR) this is discouraged from being used in CanOpen
Next 4 bits are the length, this specifies the length of the rest of the packet, or how many data bytes follow 0-8
Then up to 8 bytes of data (must agree with length bits)
CanOpen packets on the wire
As a quick note, if you are observing can open packets on the wire with a scope for example, what you see is not exactly what is described previously but is more like:-
| Description | Length |
|---|---|
| Start bit (0) | 1 |
| Can Identifier or COB-ID | 11 |
| Remote Transmission request (RTR) | 1 |
| IDE (0) | 1 |
| Reserved 0 (0) | 1 |
| Data length | 4 |
| Data | 0-64 |
| CRC | 15 |
| CRC Delimiter | 1 |
| ACK slot | 1 |
| ACK Delimiter | 1 |
| End of frame | 7 |
The Pinky read bytes are the ones describde in this document as those are the ones you have control over at the CanOpen level, the other frames should be considered a lower level and part of CAN.
But watch out for bit stuffing. Every 5 bits of the same polarity will generate a bit of the other polarity which needs to be factored in the above table when decoding the protocol. If you are using a higher level decoder on a scope, such as Picoscope offers this will handle this for you and just give you the required data which out you worring about the decoding, but handy to know if you ever need to use a scope!