Closed thesummer closed 1 year ago
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.
Oh, that is a weird thing. Thanks for the fast reply. I will try to fix it in the Python module then.
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.
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.
Should be fixed in 76baf61845d0dfeb26f36e7db8a07f2cc0f3d30b bugfix branch. Please test and give feedback.
Thank you for the fast fix, but where do I find the binaries? Is there a pipeline where I can download the artifacts?
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
Hm, can't find any email with an archive or a download link in my mailbox. Only the notifications with your replies.
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.
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.
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.
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. :-)
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.