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 the addressed device).
The request CAN ID is 0x600 + node ID. The response CAN ID is 0x580 + node ID. Thus:
665 A read request to the device with node ID 0x65
5E5 A read response from the 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 the 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:
"ready to switch on",
"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.
