FW/HW/SW version and (OD) Revision number management is unclear / incomplete

[GRoussos]

XDD files include HW/SW/FW version numbers set to 0 in the DeviceIdentity section and the CANopenEditor GUi does not expose these. Presumably, these should be linked to 0x1009/0x100A/?? as specified by CiA301 Profile.

Moreover , the CANopenEditor GUI does not provide any way to view or set the Device or File revision in the Device Info tab, although both Revision numbers are included in the FileInfo and DeviceInfo sections of EDS files respectively. XDD files do not seem to contains any such info, so maybe these fields are obsolete?

The OD revision number is set in object 0x1018.03 according to CiA 301 profile and this is manually edited but does not seem to be linked with any of the Device or File revision fields. I'm under the impression that a CANopen master might use the DeviceInfo or FileInfo revision of a EDS file to match it to a specific slave based on the 0x1018.03 value the slave is reporting.

So my questions are:

1. Regarding HW/SW version, should the values in DeviceIdentity section of XDD reflect the 0x1009/0x100A values?
2. Regarding revision: should the EDS FileInfo and / or DeviceInfo revision numbers be synced with 0x1018.03 and / or be exposed in the CANopenEditor GUI? If yes, how are these fields stored in XDD files (other than 0x1018.03)?

If any update of CANopenNode editor is needed after all to better align with CiA standards and common practices I can contribute to it. Thanks

[trojanobelix]

Please provide a XDD that shows this issue.

[nimrof]

The OD revision number is set in object 0x1018.03 according to CiA 301 profile and this is manually edited but does not seem to be linked with any of the Device or File revision fields.

Not checked how it works in the code, but that looks wrong to not link the values, at least in EDS From CiA 306(eds):

I'm under the impression that a CANopen master might use the DeviceInfo or FileInfo revision of a EDS file to match it to a specific slave based on the 0x1018.03 value the slave is reporting.

I think i have seen Weidmuller ucontrol work somewhat that way. You register a device with its EDS file and the default is that it checks if the device matches some of the identity values if not a error is given...not sure if the master stoped, but something bad happend

[henri62]

I too can confirm that the "Product code" (Device Info tab, "Product ID") is not synchronized with OD 1018:2, you have to update it (OD entry 1018:2) manually to fix it.

[GRoussos]

samplefile.zip Here is a sample XDD and EDS showing that the Identity values in the DeviceIdentity (XDD)/ DeviceInfo (EDS) sections are different to the values in 0x1018 (and 0x1008-A but I don't know if that's required by the standards)/