Learn about CANopen communication protocol. Get to know the basic terms, DS402 profiles, network management, SDO, PDO and more. Find out what are the advantages of distributed control? What is the binary interpreter method?

1. What is CANOpen ?

2. 2
What is CANOpen ? Wikipedia definition: “CANopen is a communication protocol and device profile specification for embedded systems used in automation.” CANOpen is the communication protocol that is used by the G-MAS and drives. It has been standardized by CiA – CAN in the Automation organization. Every CANOpen device has an object dictionary – a list of supported objects that can be read from and written to. These objects indicate and change the device behavior.

3. 3
Basic Terms Object Dictionary – The list of objects which are supported by a device. Some objects are mandatory and some are optional, but each object is defined in the standard. Every object has an index (address) and sub-index (entry). For example: object 0x608F has three entries – sub-indices 0,1,2. The data type, default value, and the access type (RO RW) of the object entries are defined in the standard.

4. 4
Basic Terms CAN ID – Every drive has a specific ID on the CAN bus. In order to address a specific drive, the G-MAS needs to add the Drive ID to the COB ID, so that in practice, when G-MAS sends an SDO to a drive with ID 1, it will send it with CAN ID 0x601 and will receive an answer with CAN ID 0x581 (0x602 and 0x582 for Drive 2). The range of drive IDs is 1-127.

5. 5
Basic Terms The COB ID is composed of these 11 bits: The list of function codes: These tables and additional data
can be found in the CANOpen
“application layer and communication
profile” document, p.86.

6. 6
Basic Terms
CAN Sniffer – A software and hardware utility used to monitor CAN bus traffic.
For example:
0 00000601 8 23 FF 60 00 00 00 00 00 5606.678380 R
COB - ID
Number of data bytes - 8 is the maximal number of data bytes
 message data bytes
Time - indicates the time that the message was sent Basic CANopen- FAQ

7. 7
DS301 and its Derivatives CANopen devices are divided into families. Each family has its own object dictionary and specific definitions. The most basic family is the DS301 family. All other families are derivatives of this family. DS301 – The basic family of CAN devices. It holds the basic terms (PDOs SDOs etc.) and the basic object dictionary that DS301 devices need to support (like object 0x1000 “device type”).

8. 8
DS301 and its Derivatives DS301 Family Derivatives: DS402 Servo Drives – For example Elmo drives, need to support additional objects, for example: actual position – object 0x6064. DS401 IOs – These devices have Digital/Analog Inputs/Outputs, user may write to outputs and read from Inputs. These devices may support objects like write outputs – object 0x6200. DS406 encoders - These devices send position via a predefined method. User may use these positions for application purposes.

9. 9
DS402 Profiles DS402 devices can operate in different operation modes. G-MAS can decide in what mode it wants to operate the drive: NC – G-MAS manages the drive position by periodically sending the drive positions at small predefined intervals. The motion profile is calculated by the G-MAS. Distributed – G-MAS does not manage the motion sequence, it only sends specific motion data (velocity, acceleration, target position, etc.) and waits for the drive to perform the operation, the motion profile is built by the drive.

10. 10
DS402 Profiles The DS402 defines motion profiles that either can be NC or Distributed:

11. 11
NMT- Network Management The drive has an internal communication state machine that needs to be operated by G-MAS: These tables and additional data can be found at CANOpen “application layer and communication profile” document, p.83

12. 12
NMT- Network Management The COB ID of NMT is 0x0, therefore we need to indicate the node ID in the message itself. NMT message structure (2 bytes): When a drive is detected on bus G-MAS needs to send it an NMT “start remote node” according to the state machine. NMT commands: 1 – start remote node 129 – reset node 2- stop remote node 130 – reset communication 128 – enter pre operational state
command
Node ID

13. 13
NMT- Network Management
Let’s see it via a CAN sniffer:
Node sends heartbeat boot up message: 0 00000701 1 00 17508.107790 R
COB ID 0x701 indicates a heartbeat message of drive 1
1 byte of data
State boot up
G-MAS sends NMT “start remote node” 0 00000000 2 01 01 17508.108560 R
0x0000 is the COB ID of NMT
2 data bytes
Command – 0x01 means “start remote node”
Node ID – 0x01
Now the drive is in operational state.
Additional data can be found in the CANOpen “application layer and communication profile” document, p.77.

14. 14
HEARTBEAT DS301 defines the HEARTBEAT protocol. In this protocol, the drive sends HEARTBEAT messages to G-MAS. G-MAS monitors the HEARTBEATs, per device. If a HEARTBEAT was missed, G-MAS can indicate that an error occurred and notify the user. In order to configure the device to send HEARTBEATs, the G-MAS needs to download an SDO and configure the HEARTBEATs period.

15. 15
HEARTBEAT When a CAN device sends a HEARTBEAT it also indicates its internal state. The HEARTBEAT COB ID is 0x700. Message structure (1 byte): Most significant bit is reserved (always zero). The seven other bits indicate the drive state.

16. 16
HEARTBEAT The seven other bits indicate the drive state: 0 – Boot up: When a drive is turned on, it sends this first HEARTBEAT; this is how G-MAS identifies that the drive exists on the bus. 4 – Stopped: All communication is stopped; the drive only accepts NMT messages and only sends HEARTBEATs. 5 – Operational: The drive is fully operational for all purposes; it will accept and will send all types of messages. 6 – Pre-Operational: The drive will not accept PDOs In this state. The state machine can be found on p.12.

17. 17
HEARTBEAT
What does a HEARTBEAT look like via a CAN sniffer?
00000701 1 05 6877.559220 R
COB ID – 0x701 means drive 1 sent a HEARTBEAT message
1 – byte of data
State - The drive is in state 5: operational

18. 18
EMERGENCY When an error occurs at the drive level the G-MAS needs to be notified ASAP. This is the purpose of the EMCY message. The drives sends an EMCY with three information fields that may help identify the error:

19. 19 After G-MAS indicates an EMCY message it changes the drive state to error stop. After the error has been removed, the G-MAS may send an NMT reset command and continue working normally.
EMERGENCY

20. 20
EMERGENCY
Let’s look at an emergency message that is sent from the drive:
 0 00000081 8 10 82 21 00 00 00 00 00 ..!..... 5703.092070 R
0x81 – This the COB ID of EMCY message from axis 1
8 data bytes
Emergency error code 0x8210 with Error register 0x21 means “Attempt to access an unconfigured RPDO” (Elmo Motion Control CANopen DS 301Implementation Guide, p.13-24)
Manufacturer specific error code is 0x 00 00 00 00 00
Additional data about EMCY can be found in the “Elmo Motion Control CANopen DS301 Implementation Guide” document, p. 6-1 and in the CANOpen “application layer and communication profile” document, p. 69.

21. 21
SDO – Service Data Object SDO is one of the most common messages in CAN communication and it enables a direct access to an object. When a user sends a SDO to the drive through G-MAS it can be one of the two SDOs: SDO Download – User wants to write to an object entry. SDO Upload – User wants to read an entry.

22. 22
SDO – Service Data Object The G-MAS sends the download/upload request and the drive returns a positive or a negative (SDO abort) response. A negative response is always returned with a reason for the abortion. A negative response might be returned when the object/entry does not exist or other specific reason.

23. 23
SDO – Service Data Object SDO Command Code – Specifies what kind of SDO this is (e.g., download/upload, response/request). The command code comprises the three most significant bits of the message data. Common SDO Command Codes: 1 - Initiate download request (G-MAS side) 2 - Initiate upload request (G-MAS side) 3 - Initiate download response (DRIVE side) 2 - Initiate upload response (DRIVE side) 4 - SDO ABORT response

24. 24
SDO – Service Data Object SDO download messages structure:
The first byte holds the command (download/upload, request/response).

25. 25
SDO – Service Data Object
Bytes 1-3 hold the index and sub-index of the object (they called multiplexer). Bytes 4-7 in the G-MAS message are the data bytes to download (not all bytes are necessarily used). Bytes 4-7 in the drive message are reserved, they will hold the abort code when message aborted.

26. 26
SDO – Service Data Object
How does an SDO download look at the CAN sniffer log?
Download request (G-MAS side):
 0 00000601 8 2B 85 60 00 34 12 00 00 12733.538310 R
COB ID 601 means that G-MAS sent an SDO to drive with ID = 1
8 data bytes were sent
0x2B = 0010 1011, the three most significant bits are the command code – 1 means initiate download request
Index – 0x6085 (object number) - quick stop deceleration
Sub-index - 0x0 (entry number)
Data – 0x00 00 12 34

27. 27
SDO – Service Data Object
How does an SDO download look at the CAN sniffer log?
Download response (Drive side):
 0 00000581 8 60 85 60 00 00 00 00 00 12733.537650 R
CAN ID 581 means that Drive with ID = 1 is responding
8 data bytes were sent
0x60 = 0110 0000, the three most significant bits are the command code – 3 means initiate download response
Index – 0x6085 (quick stop deceleration)
sub-index - 0x0
Data – 0x00 00 00 00 – always 0 when positive response, abort code when SDO is aborted

28. 28
SDO – Service Data Object SDO upload messages structure: Similarly to SDO download, first byte is the command and bytes 1-3 are the index and sub-index in both messages.

29. 29
SDO – Service Data Object
Bytes 4-7 in G-MAS message are reserved (no need to send data). These bytes in the drive message hold the required data (or abort code) .

30. 30
SDO – Service Data Object
How does an SDO upload looks like in the sniffer ?
G-MAS sends upload request:
0 00000602 8 40 85 60 00 00 00 00 00 6912.343960 R
COB ID – 0x602 means that G-MAS sent an SDO to drive with ID 2
8 bytes of data
0x40 = 0100 0000 – command code is 2, meaning SDO upload request
Index - 0x6085 (quick stop deceleration)
sub-index – 0x00
Data – reserved (always 0)

31. 31
SDO – Service Data Object
How does an SDO upload looks like in the sniffer?
Drive replies with:
 0 00000582 8 42 85 60 00 34 12 00 00 6912.344580 R
COB ID – 0x582 means that drive with ID 2 replies
8 bytes of data
0x42 = 0x0100 0010 - – command code is 2 meaning SDO upload response
Index - 0x6085 (quick stop deceleration)
sub-index – 0x00
Data – 0x00 00 12 34
Additional data can be found in the CANOpen “application layer and communication profile” document, p. 40

32. 32
SYNC – Synchronization Object This is a message that is sent by the G-MAS for the purpose of synchronization: The SYNC message synchronizes the handling of PDOs at the DRIVE level: For TPDO – Synchronization is with respect to transmission. For RPDO – Synchronization is with respect to processing of incoming PDOs.

33. 33
SYNC – Synchronization Object When G-MAS wants to send SYNC messages to the drives, it notifies them (by SDO download) what is going to be the SYNC sending period. G-MAS periodically sends the SYNC message on the CAN bus (everyone can see it).

34. 34
SYNC – Synchronization Object
SYNC message is addressed to all drives, therefore its COB ID does not include a Drive ID.
The COB ID of a SYNC message is 0x80.
Let’s see how a SYNC message looks like via a CAN sniffer log:
 00000080 0 2484.192160 R
COB ID – 0x80 means SYNC message addressed to all drives
Data – always 0 since the data has no significanse
Additional data in the CANOpen “application layer and communication profile” document, p. 67

35. 35
PDO – Process Data Object SDOs have a lot of overhead – only 4 bytes contain data in a normal SDO message. In order to save this overhead the PDO was created. PDO message contains only data. There are two types of PDOs: RPDO – a PDO that G-MAS sends to the drive. TPDO – a PDO that the drive sends to G-MAS.

36. 36
PDO – Process Data Object How can the G-MAS / drive tell to which object / entry the message was sent? PDO Mapping: G-MAS sends several SDOs according to the DS301 protocol and notifies the drive in advance which PDOs it wants to send/receive and in with which method. When the drive / G-MAS receives a PDO, it knows its destination and is purpose in advance.

37. 37
PDO – Process Data Object Elmo drives and G-MAS use 4 types of PDOs: PDO1 – Used for motion control. PDO2 – Used for binary interpreter messages (sending command MO = 1 through G-MAS gateway). PDO3 / 4 – Reserved for user purposes. G-MAS provides 15 TPDO mappings and 5 RPDO mappings. G-MAS also provides a user with the ability to manually map the PDOs (to non-common objects).

38. 38
PDO – Process Data Object In profile position, G-MAS maps RPDO1 to target position and control word, by default. TPDO1 is mapped to position actual value and status word. Let’s see the sniffer log of the first command in the motor on sequence: G-MAS sends RPDO1 to Drive with ID 1: 00000201 6 A0 86 01 00 06 00 13478.020790 R Drive replies with TPDO1: 00000181 6 A0 86 01 00 31 02 13478.021510 R

39. 39
PDO – Process Data Object
G-MAS sends RPDO1 to Drive with ID 1:
00000201 6 A0 86 01 00 06 00 13478.020790 R
COB ID – 0x201 means RPDO1 directed to drive with ID 1
6 bytes of data
target position 0x 00 01 86 A0
Control word 0x 00 06
The drive knows in advance which bytes are related to the control word and which are related to target position, since the G-MAS performed PDO mapping before sending the PDO.

40. 40
PDO – Process Data Object
Drive replies with TPDO1:
00000181 6 A0 86 01 00 31 02 13478.021510 R
COB ID – 0x181 means TPDO1 sent from drive with ID 1 to G- MAS
6 bytes of data
position actual value 0x 00 01 86 A0 = 100,000
Status word 0x 02 31

41. 41
PDO – Process Data Object PDOs can be sent synchronically and asynchronically. The method is determined by the PDO mapping. RPDO might be sent from G-MAS:
•With every SYNC message.
•With every change in the object value. TPDO might be sent on Drive:
•With every SYNC message.
•With every change in the object value.
•By timer value. Additional data in the CANOpen “application layer and communication profile” document, p. 33.

42. 42
Control Word Control Word – Object 0x6040 sub-index 0. This is a very important object. G-MAS uses it to send to the commands to be executed (e.g., “set motor on”) the drive. The CW structure is:
Each bit has a role, affecting the drive behavior.

43. 43
Status Word Status Word – Object 0x6041 sub-index 0. This is another important object. The drive updates its status to this object, so that by sampling this object the G-MAS knows the drive status (e.g., is motor on?). The SW structure:

44. 44
Drive FSTM G-MAS changes the drive FSTM according to this state machine diagram: The state machine and additional data can be found at CANOpen “drives and motion control device profile” document, p. 22.

45. 45
Example – ‘Motor On’ Sequence G-MAS and the drive perform a handshake protocol for turning the motor on. In profile position, RPDO1 is mapped to Control Word and Target Position. TPDO1 is mapped to Status Word and Position Actual value. The transitions in the following example are according to the DS402 state machine described.

46. 46
Let’s see the sniffer log of a motor on sequence:
G-MAS sends RPDO1 to drive 1:
0 00000201 6 FF FF FF FF 07 00 19571.810470 R
Control word 0x 00 07 = 0000 0111
We can look at the “bits of the controlword” table
Drive 1 replies with TPDO1
0 00000181 6 FF FF FF FF 33 02 19571.809580 R
Status word 0x 02 33 = 0010 0011 0011
From looking at the “state coding” table:
This is only the DS402 state, the motor is not on yet.
Example – ‘Motor On’ Sequence

47. 47
Let’s see the sniffer log of a motor on sequence:
G-MAS sends:
0 00000201 6 FF FF FF FF 0F 00 19571.805490 R
Control word = 0x 00 0F = 1111
From looking at the table:
Drive replies with:
0 00000181 6 FF FF FF FF 37 06 19571.802550 R
Status word – 0x 06 37 = 0110 0011 0111
From looking at the table:
And now the motor is on!
Example – ‘Motor On’ Sequence

48. 48
Example – ‘MoveAbsolute’
Let’s see the sniffer log of a moveabsolute sequence in profile position:
First of all G-MAS sends SDOs to indicate the desired acceleration (0x6083), deceleration (0x6084) and velocity (0x6081) all with sub-index 0x0:
0 00000601 8 23 83 60 00 40 42 0F 00 14529.534180 R
0 00000581 8 60 83 60 00 00 00 00 00 14529.533530 R
0 00000601 8 23 84 60 00 40 42 0F 00 14529.533120 R
0 00000581 8 60 84 60 00 00 00 00 00 14529.532370 R
0 00000601 8 23 81 60 00 40 42 0F 00 14529.531980 R
0 00000581 8 60 81 60 00 00 00 00 00 14529.531530 R
All of these objects received the value of 0x 00 0F 42 40 = 1,000,000

49. 49
Example – ‘MoveAbsolute’ Now G-MAS and Drive handle a handshaking protocol: CW: SW: This chart and additional data can be found in the CANOpen “drives and motion control device profile”, document p. 43.

50. 50
Example – ‘MoveAbsolute’
G-MAS sends RPDO1 with the target position and control word:
0 00000201 6 E8 03 00 00 3F 00 14529.530460 R
COB ID – 0x201 means RPDO1 to drive 1
Target position - 0x 00 00 03 E8 = 1000
Control word – 0x 00 3F = 0011 1111 – enable operation + bit 4 set new point is raised
Drive replies with TPDO1:
0 00000181 6 FF FF FF FF 37 16 14529.529690 R
0 00000181 6 FF FF FF FF 37 12 14529.528210 R
COB ID – 0x181 means TPDO1 from drive 1
Position actual value- 0x ff ff ff ff = -1
Status word – 0x16 37 = 0001 0110 0011 0111 – operation enabled + target reached +ack
Status word – 0x12 37 = 0001 0010 0011 0111 – operation enabled + target not reached +ack

51. 51
Example – ‘MoveAbsolute’
G-MAS sends RPDO1 with the target position and control word:
0 00000201 6 E8 03 00 00 2F 00 14529.530460 R
COB ID – 0x201 means RPDO1 to drive 1
Target position - 0x 00 00 03 E8 = 1000
Control word – 0x 00 2F = 0010 1111 – enable operation + bit 4 is down, now G-MAS waits for target reached indication
Drive replies with TPDO1:
0 00000181 6 00 00 00 00 37 02 14529.529690 R
0 00000181 6 E8 03 00 00 37 06 14529.528210 R
COB ID – 0x181 means TPDO1 from drive 1
Position actual value- in the first TPDO it’s 0 (next value after 0xff ff ff ff = -1) in the second it’s 1000
Status word – 0x02 37 = 0000 0010 0011 0111 – operation enabled + target not reached
Status word – 0x06 37 = 0000 0110 0011 0111 – operation enabled + target reached – motion ended

52. Getting Started with CANopen Communication