Skip to content
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

Typo in generatd DCF file #46

Closed
thesummer opened this issue Feb 15, 2023 · 13 comments
Closed

Typo in generatd DCF file #46

thesummer opened this issue Feb 15, 2023 · 13 comments

Comments

@thesummer
Copy link

Hello,

I used the CANopenEditor version 4.0-104-g6f50f73 to configure some nodes and generate a coresponding DCF.
In the DCF I noticed that the block with the general device setup is generated as [DeviceComissioning] while it should be [DeviceCommissioning] (with "mm").

It's a small type, but it prevents for example https://canopen.readthedocs.io/en/latest/ to read in the generated DCF.
I looked for the string in the source code and fix it myself, but couldn't find it.

Do you have any suggestions? It seems to be one of the few parts where it is not possible to rename the field through the GUI.

@trojanobelix
Copy link
Collaborator

trojanobelix commented Feb 15, 2023

Unfortunately, the standard (DSP306) defines the section with "DeviceComissioning". Clearly a typo, but unfortunately defined exactly like this.

This is why the file is written in conformity with the standard. A tool that evaluates this should therefore at least accept this way of writing.

@thesummer
Copy link
Author

Oh, that is a weird thing. Thanks for the fast reply. I will try to fix it in the Python module then.

@trojanobelix
Copy link
Collaborator

trojanobelix commented Feb 17, 2023

DSP306 Version 1.1 Date: 29.06.2001 stated
5.3 Device Commissioning
There is an additional section in the DCF named DeviceComissioning:
(...)
Example:
[DeviceComissioning]

I do not have access to never versions of DSP306, maybe some one can take a look and report any changes.

@thesummer
Copy link
Author

I just checked the version 1.3.0 from 2005. The typo with DeviceComissioning is still there, but I think I found a smaller thing which is on the CANopenEditor side.

There shall be an additional section in the DCF named DeviceComissioning:
NodeID shall indicate the device’s address (Unsigned8)
NodeName shall indicate the node name (max 246 characters)
Baudrate shall indicate the device’s baudrate (Unsigned16)
NetNumber shall indicate the number of the network (Unsigned32)
NetworkName shall indicate the name of the network (max 243 characters)

In a generated DCF with CANopenEditor I got

[DeviceComissioning]
NodeId=1
NodeName=
BaudRate=500
NetNumber=0
NetworkName=

So, NodeID and Baudrate seem to be a little off with the capitalization.

@trojanobelix
Copy link
Collaborator

Should be fixed in 76baf61 bugfix branch.
Please test and give feedback.

@thesummer
Copy link
Author

Thank you for the fast fix, but where do I find the binaries? Is there a pipeline where I can download the artifacts?

@trojanobelix
Copy link
Collaborator

Thank you for the fast fix, but where do I find the binaries? Is there a pipeline where I can download the artifacts?

I release the binaries at irregular intervals, though I have been able to do at least a minimal test cycle.
You have received an email with the binaries

@thesummer
Copy link
Author

Hm, can't find any email with an archive or a download link in my mailbox. Only the notifications with your replies.

@trojanobelix
Copy link
Collaborator

@thesummer
Copy link
Author

thesummer commented Feb 21, 2023

Thank you very much. I can confirm that this fixes the behavior.

PS: I have got an email from microsoft that your email was put into quarantine. Seems like it flagged the binaries inside the archive.

@CANopenNode
Copy link
Owner

Hi,

In the latest standard (2019) there is still:

7.3.5 Device commissioning
There shall be an additional section in DCF with the entry DeviceComissioning...

I think, this is intended, keyword in the standard can't just change.

@thesummer
Copy link
Author

I also just noticed that according to the standard the keys are not case sensitive. So strictly speaking this change wasn't even necessary. Sorry for the noise.

@trojanobelix
Copy link
Collaborator

It's okay, it can be good that others don't fit the standard. It doesn't hurt and I still had some life time left. :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants