CANopenNode
TIME_OF_DAY support (again?)
When using the editor (V 4.2.3) it is not possible to choose the TIME_OF_DAY type (0x000C) for an SDO while it is formally defined in the CANOpen specification (See $7.1.6.5 CiA 301).
That is a problem because in the generated EDS file the type is incorrect and needs to be manually adjusted.
I searched through the issue list and found a partial discussion about it and (#134) that says it was implemented but that seems not to be the case. I can only find some references in the *.cs files. Also in CanOpenNode there is nothing anywhere in the C/H files that looks like it.
So what is the status about this type? Was it removed later or never merged?
I would at least expect that you can choose the TIME_OF_DAY in the editor and save it in the xdd file. I'm aware that the underlying structure is "highly unportable" because if the bitfields. But at least we could make an array of 6 bytes and let the (C) code (in CANopenNode) decode the fields to a normal struct, containing native C-types that always work.
Currently I have to workaround it by using an OCTET_STRING in the editor and in the C/H-code do this fiddling of fields myself.
Unfortunately I have virtually no skills in C#, else I could have helped with it.
-edit- See also the discussion in: https://github.com/CANopenNode/CANopenNode/issues/148 Here it says that TIME_OF_DAY is not used in the object dictionary, but that is not true. Is can also be used there.
-edit- About alignment of datatypes inside a PDO mapping: It gets even funnier, there are also datatypes (some of the "void" OD locations < 0x5) that are pointed to (as filler bits) in PDO mappings to get SDOs neatly aligned to a byte or word boundary to ease the implementation. These types are also missing. I have seen that somewhere; they used VOID4. Maybe I can find it back to show a practical example where that is done.
When using the editor (V 4.2.3) it is not possible to choose the TIME_OF_DAY type (0x000C) for an SDO while it is formally defined in the CANOpen specification (See $7.1.6.5 CiA 301). That is a problem because in the generated EDS file the type is incorrect and needs to be manually adjusted.
That is correct for canopennode v4, if you switch to legacy then time_of_day and more datatypes can be selected.
I searched through the issue list and found a partial discussion about it and (#134) that says it was implemented but that seems not to be the case. I can only find some references in the *.cs files. Also in CanOpenNode there is nothing anywhere in the C/H files that looks like it. So what is the status about this type? Was it removed later or never merged?
@CANopenNode could elaborate on time_of_day in canopennode v4, i am still on legacy version :(
I would at least expect that you can choose the TIME_OF_DAY in the editor and save it in the xdd file.
Agree, there are good reasons for why it was done so in the first place, but it has its downside so i want to fix it the the next version of the GUI.
I'm aware that the underlying structure is "highly unportable" because if the bitfields. But at least we could make an array of 6 bytes and let the (C) code (in CANopenNode) decode the fields to a normal struct, containing native C-types that always work. Currently I have to workaround it by using an OCTET_STRING in the editor and in the C/H-code do this fiddling of fields myself. Unfortunately I have virtually no skills in C#, else I could have helped with it.
I can do the c# that part if Janez agree
-edit- See also the discussion in: CANopenNode/CANopenNode#148 Here it says that TIME_OF_DAY is not used in the object dictionary, but that is not true. Is can also be used there.
Think it was for the legacy version, nothing is change on that part of the code for over 3 years https://github.com/CANopenNode/CANopenEditor/blob/f4694cd0f14aba5e1af4a9803c02f8729c3d5699/EDSEditorGUI/DeviceODView.cs#L69-L87
-edit- About alignment of datatypes inside a PDO mapping: It gets even funnier, there are also datatypes (some of the "void" OD locations < 0x5) that are pointed to (as filler bits) in PDO mappings to get SDOs neatly aligned to a byte or word boundary to ease the implmeentation.
That is dummy mapping and is from the standard and pretty normal, you map the datatype definition (index 1-0x25) of some (or all?) of the type definition and it will ack as /dev/null on read/write, but still take up space in the pdo mapping
These types are also missing. I have seen that somewhere; they used VOID4. Maybe I can find it back to show a practical example where that is done.
Not sure how it is done, but the dummy mapping implementation can look strange because its not normal mapping.
If you want truly to understand something, try to change it! Kurt Lewin
I see now that the legacy version can be selected in "Tools ->Preferences" under the name "Selected exporter". But I would never expect that this also influences the editor. I would expect that it only changes the export format, so that configuration option is at least very misleading.
Also legacy would suggest that you get less features, not more. So whats the difference? Is that documented somewhere?
We are always between "making things simple and manageable" and "supporting all the standard says". It is not always easy. I was trying to be practical. EDS specification has all those data types like "INTEGER56" or "TIME_OF_DAY", but I just don't see practical benefits of using that. Maybe some CANopen tool has problems, if those types are omitted, but it is theirs problem.
time is fully implemented in CANopenNode. If "TIME_OF_DAY" data type has to be used as an OD entry, it can be added by custom code.
XDD standard does not mention TIME_OF_DAY, I don't know how to store it there.
However, I agree, "TIME_OF_DAY" and other should be available in OD editor and EDS exporter. All data types are also available in our new protobuffer specification.
Some history about "legacy" vs "V4":
- CANopenNode V4 uses different custom properties then older CANopenNode. So GUI for OD is a little different, depending on "Selected exporter" setting. This is not very good approach and also whole OD Editor is currently little messy and poorly documented by readme, etc.
- Actually we don't need "Selected exporter" setting, one should be able to edit all OD properties.
- For "V4" unused data types was removed from the dropdown box. It would be very impractical to offer unusable options to (new) users.
- Some more advanced users would like to have additional options.
- We should keep GUI clean
@nimrof, we had discussion about "Selected exporter" option before and here are my proposals for the new GUI:
- New GUI, DeviceODView, should include all custom properties for "Legacy" and "V4" CANopenNode exporter.
- It should be able to include all data types (in dropdown box) and...
- "Selected exporter" setting should be removed. We will update all places, where it is currently used.
- ... and there must be settings, where user can configure, what is displayed inside DeviceODView. Settings should enable user to select when to display individual properties for "legacy CANopenNode" and individual data types. See example below:
Settings for "Object Dictionary" tab
Nonstandard properties:
- [x] Show "Enabled" (nonstandard property)
- [x] Show "Count Label" (related to CANopenNode V4)
- [x] Show "Storage Group" (related to CANopenNode V4)
- [ ] Show "PDO flags" (related to CANopenNode Legacy) ...
Data Type dropdown:
- [x] Show INTEGER8
- [x] Show INTEGER16 ...
- [ ] Show TIME_OF_DAY
- [ ] Show INTEGER40 ...
A note from me, I am unsure whether this always makes sense. In my opinion, the exporter setting is a project property and not one of the GUI. The setting should therefore be saved in the project file.
Or in other words: It is annoying if you have V4 and legacy projects to always remember to change the exporter selection.
@nimrof, we had discussion about "Selected exporter" option before and here are my proposals for the new GUI:
* New GUI, DeviceODView, should include all custom properties for "Legacy" and "V4" CANopenNode exporter.
Agree ✅
* It should be able to include all data types (in dropdown box) and...
Implemented (every datatype defined in protobuffer file) ✅
* "Selected exporter" setting should be removed. We will update all places, where it is currently used.
Agree ✅
* ... and there must be settings, where user can configure, what is displayed inside DeviceODView. Settings should enable user to select when to display individual properties for "legacy CANopenNode" and individual data types. See example below:Settings for "Object Dictionary" tab
Nonstandard properties:
* [x] Show "Enabled" (nonstandard property)[x] Show "Count Label" (related to CANopenNode V4)[x] Show "Storage Group" (related to CANopenNode V4)[ ] Show "PDO flags" (related to CANopenNode Legacy) ...Data Type dropdown:
* [x] Show INTEGER8[x] Show INTEGER16 ...[ ] Show TIME_OF_DAY[ ] Show INTEGER40 ...
I agree with the intention/general idea, but I ideally want more time to think this through and discussing before writing it in "stone"
A note from me, I am unsure whether this always makes sense. In my opinion, the exporter setting is a project property and not one of the GUI. The setting should therefore be saved in the project file.
Or in other words: It is annoying if you have V4 and legacy projects to always remember to change the exporter selection.
That is imho a better idea than what i had in my head
I am almost done with profile importer, after that save and open that should be straight forward. When that is done I can try to do settings+++ and PDO (that should not need that much discussion)
Sadly i don't have a loot of time to this project at the moment and looks like it will stay like that few more weeks/month
Thanks for all the answers and the discussion. You were talking about the XDD standard? What are you referring to? Is that something official or something done here in this project how to store the project data?
By the way, I implemented the TIME_OF_DAY in a codesys PLC project a month ago that accesses the OD (in an embedded system using CANopenNode). That code is going to be used by some 3-rd party that needs it too. So I'm crossing my fingers to see if they interpret the bits the same way because I never could find any correct / descent documentation or example that was correct. They were all flawed. I will probably know that in 2 weeks or so.
-edit- About the XDD are you referring to CiA311?
A note from me, I am unsure whether this always makes sense. In my opinion, the exporter setting is a project property and not one of the GUI. The setting should therefore be saved in the project file. Or in other words: It is annoying if you have V4 and legacy projects to always remember to change the exporter selection.
That is imho a better idea than what i had in my head
I am almost done with profile importer, after that save and open that should be straight forward. When that is done I can try to do settings+++ and PDO (that should not need that much discussion)
Yes, this is also a good idea.
Second option is to completely avoid exporter setting. User could export to CANopenNode exporter v1.3 or v4 or both from the same project. There would be some adaption in exporter v1.3 regarding PDO, but not a big deal. The rest of CANopenEditor would then be totally independent of CANopenNode exporters.
Thanks for all the answers and the discussion. You were talking about the XDD standard? What are you referring to? Is that something official or something done here in this project how to store the project data?
Yes, XDD is from CiA311. There is also CiA1311, which is used for CAN FD. It is simplified version of CiA311. The oldest CiA306 1.3 and set of new standards CiA306. Quite a lot of standards.
For internal storage inside CANopenEditor we are trying to switch to custom CanOpen.proto. And use it to import/export to any format.