DataType 0x40/0x41 crashes in eds.py line 152

[Sandyman]

I'm currently working with an EDS file that has objects with DataType 0x40 and 0x41. For instance:

[2020sub4]
ParameterName=@XyzXyzXyz
ObjectType=0x7
AccessType=RW
DataType=0x40
DefaultValue=0x0
LowLimit=0x3
HighLimit=0x1
PDOMapping=0

(I have changed the parameter name.) Because of an earlier bug fix that seems to involve CANFestival (which we don't use), it tries to eds.get a non-existing section. This crashes the application with a NoSectionError. See eds.py line 152.

I don't quite understand the reason for the original bug fix, but it seems to be a bit too indiscriminate in what it tackles?

Let me know if you need any more information, I'd be happy to help.

[christiansandberg]

I'm not familiar with how these complex data types are used. How should the data be interpreted in this case?

[Sandyman]

Apparently they are defined as INTEGER2 and UNSIGNED2, respectively.

I'm wondering whether the clause var.data_type > 0x1B: on line 147 isn't too broad? I don't fully understand the comment that goes with the CANFestival bug fix, but it seems very indiscriminate: any data_type > 0x1B is assumed to have been created by CANFestival?

[christiansandberg]

I'm not sure it is specific to CANFestival though, it's just a non-standard data type that has to be specified somehow, preferably in the Object Dictionary itself. The current solution is not complete however, more of a workaround.

For now we could check if the item exist in the Object Dictionary, if not we could assume it is a DOMAIN type and require the application to parse the raw binary data instead since we don't know what the data is.

[Sandyman]

I managed to work around it for now, but I'm not sure that's future proof. (I added a 'sub' not in section to the if statement.) I don't think that's a good solution necessarily, so no pull request for that one.

I don't know enough of the OD or DOMAIN types to validate your last statement. :)