SDO data size truncated to length of the default value in the EDS

[iurly]

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:

[100A]
ParameterName=Manufacturer_software_version
ObjectType=0x7
;StorageLocation=RAM
DataType=0x0009
AccessType=const
DefaultValue=3.00
PDOMapping=0

when trying to read node.sdo[0x100a].raw

• Up to version 0.6.0, I would get the whole string
• From version 0.7.0 onwards, I would get it truncated to the first 4 characters (length of default value 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?

[iurly]

Actually it looks there is a bug on the node firmware:

  can0  615   [8]  40 0A 10 00 00 00 00 00
  can0  595   [8]  41 0A 10 00 04 00 00 00
  can0  615   [8]  60 00 00 00 00 00 00 00
  can0  595   [8]  00 61 63 63 6D 69 63 2D
  can0  615   [8]  70 00 00 00 00 00 00 00
  can0  595   [8]  15 30 2E 35 2E 31 00 00

Which plainly indicates "4" as its data size.
Is there any way to work around that?

[christiansandberg]

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?

[iurly]

I totally agree and I don't have an answer to your question. :-(
Point is, software that was working before (perhaps by mistake) is now broken after upgrading and for some reason I'm not able to install the old version.
If such an inconsistency exists, perhaps a global setting could be used to resolve this.
At any rate, could you point out what the affected code area is, so that I can at least monkey-patch it for now?

[iurly]

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.
Using that implementation as the SDO client (as well as the SDO server, which is the one with the issue right now), I never noticed that bug.

[iurly]

Hi @christiansandberg, are you planning on making a new release with this change included, any time soon?

[christiansandberg]

v0.8.1 is now uploaded to PyPI.