-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SDO data size truncated to length of the default value in the EDS #135
Comments
Actually it looks there is a bug on the node firmware:
Which plainly indicates "4" as its data size. |
I’m not sure how to handle that situation. CANopen is a bit weird in the sense that the size is specified twice. Both for the whole data and for each segment. What happens if they differ? Which one takes precedence? |
I totally agree and I don't have an answer to your question. :-( |
FWIW, CANopenNode implementation apparently gives precedence to the actual transfer size (thereby ignoring the actual value reported in the first packet), contrary to what python-canopen (this package) does starting from v.0.7.0. |
Hi @christiansandberg, are you planning on making a new release with this change included, any time soon? |
v0.8.1 is now uploaded to PyPI. |
When trying to read (download) string SDOs from a node, the value returned by
.raw
is truncated to the length of the value contained in the EDS, even though the node returns a longer value.For instance, if I have:
when trying to read
node.sdo[0x100a].raw
3.00
), even though everything looks correct on the wire.This is probably related to PDO and SDO expected and actual data size #64.
Am I doing something wrong?
The text was updated successfully, but these errors were encountered: