Bug: CANopenNode only responds to SDO upload request with 8 bytes of data
CANopen based stack for communication in embeded control systems.
Brought to you by:
jani22
Menu
▾
▴
An SDO upload request contains 4 bytes of data.
CANopenNode only seems to respond to SDO upload requests that contain 8 bytes (DLC=8), ignoring the last 4 bytes.
Steps to reproduce:
1. Send an SDO upload request with data length code 4, containing 4 bytes (command + index + subindex).
Expected: SDO upload response.
Actual: No response.
Workaround is to send 8 bytes, with the last 4 bytes set to anything.
Workaround note: If CANopenNode devices are used with other devices that do not have this issue, and minimizing bandwidth is desired, a solution is for host software to optionally pad upload requests depending on the device type / user configuration (this is the strategy we are using in our control software).
Note: It works with libcanopen (and some other utilities, such as Fullmo) because libcanopen happens to be lax about sending the minimum necessary data for certain frame types, and uses a fixed-length 8 byte buffer to send upload requests.
Sorry I do not have a patch. If and when I have the time I will attempt to locate and fix the issue and submit one. In the mean time, I am reporting the issue.
Thanks,
Jason
I think that according to EN 50325-4 (section 5.1.3.3.6 for SDO upload protocol) all SDO messages have to be 8 Bytes long.
It seems OK to me that the Canopen stack do not answer to messages with a DCL different from 8.
Martin
Martin,
You are correct, I'm not sure where I picked that up but it was a long time ago. In reading it it shows that the final 4 bytes are present in the request, marked as "reserved, must be 0". Sorry about that and thank you for pointing that out.
Incidentally, which version of the document are you referring to? In 4.2.0 (Feb 2011, the most recent), Section 5.1.3.3.6 does not exist. SDO upload protocol is described in 7.2.4.3.6.
Oddly, the other devices I have here (currently Ingenia Pluto DC Servo Drives) respond to 4-byte requests, which technically it looks like they shouldn't do. Although since they do, I might as well keep sending 4-byte requests to those drives (our firmware versions are frozen) just to minimize bandwidth, because I can.
Thanks again and apologies,
Jason