# Decoding message data on this CAN bus

I am working with the CAN bus and need some help with decoding message data.

Here is a sample of the data that I'm seeing on the CAN bus.

root@petalinux:/var/volatile/tmp# /tmp/candump -n 10 can0
can0  4E5   [4]  F0 16 00 00
can0  665   [8]  40 78 60 00 00 00 00 00
can0  5E5   [8]  4B 78 60 00 DB 00 00 00
can0  665   [8]  40 64 60 00 00 00 00 00
can0  5E5   [8]  43 64 60 00 E4 7D 5E 00
can0  665   [8]  40 41 60 00 00 00 00 00
can0  5E5   [8]  4B 41 60 00 27 02 00 00
can0  665   [8]  40 41 60 00 00 00 00 00
can0  5E5   [8]  4B 41 60 00 27 02 00 00
can0  665   [8]  40 6C 60 00 00 00 00 00
root@petalinux:/var/volatile/tmp#


I can't figure out how to trace the data back to a particular CAN bus message.

My device has a node ID of 101 (base 10) and it is a StepIM stepper motor. Here is a reference to the manual - http://servotronix.com/wp-content/uploads/dlm_uploads/2015/05/stepIM_CANopen_fw0.0.2.85_Rev.1.3.pdf. So let's try and decode the last message from above. That would be "can0 665 8 40 6C 60 00 00 00 00 00"

I can't seem to figure out how to translate the hex string "*40 6C 60.." into a command the document for the stepper motor knows about...

• the stepIM are with CANopen protocol which is a higher protocol based on CAN bus. Please exchange tag CAN with CANopen. – Tom Kuschel Aug 11 '17 at 21:04

You haven't explained what exactly your listing shows, but it might be the message ID, followed by the number of data bytes in brackets, followed by the actual data bytes. Nothing seems to be explicitly stating whether the IDs are 11 or 29 bit. Perhaps just by using 3 HEX digits for the ID this listing indicates 11 bit IDs. If so, it would show 8 HEX digits for 29 bit IDs.

What each line is therefore (it seems) showing you is one CAN message. There is nothing more to decode to understand the CAN message. It is shown to you explicitly.

For example, the last line says that a message was seen with ID 665h (1637 decimal), that this message had 8 data bytes, and that the data bytes were (in HEX) 40, 6C, 60, 0, 0, 0, 0, and 0. The first three would be 64, 108, and 96 in decimal.

As for what the meaning of that message is to whatever device originated it or is intended to act on it, that's something you have to look up in the documentation of the specific devices. That's a layer above CAN.

My device has a node id of 101

There are no node IDs in CAN, only message IDs. If your devices use the concept of a node ID, then this is something particular to a protocol layer above CAN. The CAN standard can't help you with that. You have to consult the specific device documentation, which might refer to the higher level protocol it uses above CAN, possibly in a separate document.

• It's not basic CAN, it is CANopen, as seen in Manual. – Tom Kuschel Aug 11 '17 at 21:06
• I have elaborated on it in my answer. – Peter Mortensen Apr 5 '18 at 12:12

Except for the first message, this is typical SDO traffic (CANopen), with request/response pairs:

0x665   SDO request  (range 0x600 - 0x67F, depending on the node ID)
0x5E5   SDO response (range 0x580 - 0x5FF, depending on the node ID)


For the first pair, a dead giveaway is the 0x4B in the first byte of the response. This indicates that the returned data is of size two bytes (for one byte and four bytes, it is 0x4F and 0x43, respectively). The 0x40 in the first byte of the request indicates it is a read request (the standard uses a different term, "Upload", with the opposite meaning as on the Internet (download) - it is from the perspective of addressed device).

The request CAN ID is 0x600 + node ID. The response CAN ID is 0x580 + node ID. Thus:

665   Read request to device with node ID 0x65
5E5   Read response from device with node ID 0x65


For SDOs the CANopen index and subindex is in the second, third, and fourth byte (least significant byte first for the CANopen index). So for the first pair, 40 78 60 00, the requestor says: "Device at node ID 0x65 (101), give me your stored value at 6078sub0".

In this case the information is flowing from the addressed device to whoever made the request (the requestor can not be seen from the CAN bus log, but it is usually a central controller in the system or a service tool running on a PC (usually a USB-to-CAN adapter)).

Thus, for the shown traffic, read requests are made for (the response for the last one is not included in the posted CAN bus log):

6078sub0   (2 bytes, 0xDB00 = 219)
6064sub0   (4 bytes, 0x005E7DE4 - 6,192,612)
6041sub0   (2 bytes, 0x0227 - 551)
6041sub0   (2 bytes, 0x0227 - 551)
606Csub0   (?? bytes)


Strangely, the request for 6041sub0 is repeated.

Furthermore, even though SDOs are usually only for configuration information, the CANopen index range 0x6000 to 0x6FFF is usually used for non-configuration information, like measured quantities or status.

### Diving into the manual

The SDO indexes / subindexes can be looked up in the manual (I have included actual values from the sample CAN bus log):

6078sub0   Motor current, 219 mA
6064sub0   "Position Actual Internal Value" is 6,192,612
6041sub0   Statusword, 0x0227 = 0000 0010 0010 0111, meaning:
"switched on",
"operation enabled",
"quick stop"
"remote"
606Csub0   "Velocity Actual Value". The value is not included,
but it is a 32-bit signed integer.


### The first message

Assuming the first message is also CANopen, 4E5 F0 16 00 00: For all CANopen CAN messages the ID is a four-bit function code (0-15) followed by a seven-bit node ID. In this case, 0x4E5 = 1001 1100101b. Thus the function code is 1001b = 9, meaning "PDO4, transmit". The direction of information flow for PDOs (despite, in this case, "transmit") is a matter of definition (depends on the application). The node ID is 1100101b = 0x65.

The node ID for the PDO is the same as for the SDOs.

The information in this PDO, "Transmit PDO 4", is contained in SDO 0x1A03, "Transmit PDO Mapping Parameter 4". If it has not been changed from the default, the data in the PDO is the same as SDO 0x60FAsub0, a signed 32-bit integer:

the control effort as the output of the position control loop. In the position control function, notation of the control effort is mode-dependent and therefore not specified.

### Conclusion

The motor device with node ID 0x65 sends out the control effort (likely at regular time intervals) using a PDO.

A controller or a real-time monitor window in a service tool reads and display other measured quantities / status from the same motor device using SDOs.

• I work with this kind of CAN bus data on a daily basis, so this is easily recognisable. However, the precise interpretation/meaning depends on information about the particular system. I thought this question deserved a comprehensive answer. – Peter Mortensen Oct 11 '17 at 20:52

The device uses a CANopen protocol. CANopen is a CAN-based communication system. It comprises higher-layer protocols and profile specifications.

It is used in Automation. There are several protocol analyzers to figure out the whole communication. The automation system using CANopen is a master/slave architecture. You'll find some information at wikipedia about CANopen, but it's not so trivial as the message oriented CAN itself.

• Yes, that is correct. It is CANopen. – Peter Mortensen Oct 11 '17 at 21:08

To decode the communication, you have to know motor CANopen Object Dictionary. It looks like TPDOs and their content depends on communication and mapping objects.

You should to study following terms from CANopen to understand the protocol. - Object Dictionary - Process Data Objects (PDO) - Communication parameters - Mapping parameters