Possibility to use EDSSharp to create EDS/XDD OD descriptions joining / modifying a base OD with optional OD patches?

[GRoussos]

I am working on the development of a product family using CANopen. 90% of the OD of all devices is shared but there are differences between them, owing to:

• Product information (eg. device type, etc)
• HW differences
• Feature differentiation

I am thinking it would be great if we can expand (or use existing features of) EDSSharp so that we can have a base OD definition (EDS/XDD) and then apply "patches" to it which will add, remove, or modify ID entries. This way for example it will be easy to programmatically create the ODs for different devices sharing a common OD base but with different features which enable different OD entries. Instead of that currently we have to maintain multiple OD definitions that share 90% of the entries.
Maybe this is already possible, I have seen references of EDS "modules", don't know if that is something similar to what I describe above.
I would be interested in contributing to such an effort for CANopenEditor / EDSSharp

[trojanobelix]

A contribution is always welcome.

The module concept may be suitable for your needs.
The purpose of the module concept is described in DSP306 that can be found in the web (likley not the actual version, but a good start):
A very common method of building flexible devices is to use a bus coupler that can be extended by modules. The basic device automatically recognises the presence of extension modules.

The CANopenNodeEditor supports the module concept, but is currently not actively maintained. It is therefore very likely that it contains bugs and that the DSP306 standard is only implemented incompletely.

If the concept is suitable for your requirements, it would be great if you could promote further development in the CANopenNodeEditor.
An implementation in line with the CiA standard is important.

[GRoussos]

Thanks for the reply @trojanobelix !
The modules concept seems a good starting point I think, though it does not solve my needs completely and I have a few ideas in mind about it.
To clarify, I also need to keep the implementation / resulting EDS/XDD compliant with the respective CiA standards.
If you are interested and able to discuss this more, here are the aspects of modules that I like and what I would like to see improved (or clarified) in the EDSSharp and CANopenEditor:

• Modules provides a convenient and standards-compliant way to define optional/modular sets of OD entries. The ability to edit and view everything through the same tool we are using already (CANopenEditor) is a big plus. But...
• CANopenEditor seems to only support viewing modules, not editing them
• I don't know yet if a module can override (at least set the value but also possibly data types, SubIdxs, etc) or delete an object in the main part of the OD. Not a showstopper but would be nice
• I don't know if it's OK for modules to have conflicting OD entries. If supported, that could solve the issue above, i.e. move all conflicting OD entries to modules and each time use only one of them.
• I understand that modules need to be enabled by the device at runtime - happy to be corrected here. In our case the differences between OD/product variants are known at compile time so having a way to fix the module selection at build will be a plus.
• Even more so, ideally we would like to have a base OD with lots of modules and use it to generate EDS/XDD without modules but with the objects of the enabled modules for each permanently added to the OD of each variant. Thus, from the host / EDS consumer perspective there will not be any modules.

From my point of view adding functionality in EDSSharp / CANopenEditor to handle the above topics would not break CiA standards compliance - especially in the generated EDS/XDD files. There may be a few aspects in the handling of modules that could conflict with or extend beyond CiA specifications, eg. module objects overriding / deleting base objects. For such cases we could add an option for "extended" module functionality, making it clear that this is beyond the CiA standards. And more importantly, the output will still need to be CiA compliant.
Sorry for the long post, I'm excited to see there is already a starting point for what I would like to achieve! Feel free to disagree with any or all of the above! Unless there are objections I would like to add this functionality to CANopenEditor repo and not fork it (publicly or privately) as I would like to contribute back what I can and I believe this can be useful for others too.

[nimrof]

If modules does not work out i have a suggestion instead of forking.

As you might know we are currently slowly working on a long time project of using a protobuffer based object as the main dataobject instead of the expanded eds used in CanOpenEditor and EDSSharp.

If its not that much stuff that is changed you could do something like this:

1. Use CanOpenEditor to make your base OD.
2. Use CanOpenEditor to make your different "patch" OD.
3. Save it
4. Use EDSSharp to convert the base and "patch" od to protobuffer
5. Use your favorite language to patch it using values from different OD.
6. Use EDSSharp to convert the changed protobuffer into what format you want.

That way you can output different perfect CiA files & CanOpenNode file

Just be warned that the protobuffer definition is in beta and not stable at the moment (do not use it for longtime storage), but that can also be a good thing as you can very easy influence it.
Would you like a "merge extension" that says if a object/subobject should be removed/replaced then make a suggestion.

[trojanobelix]

It would be really great if we could expand and improve CANopeEditor at this point
Unfortunately, I have no experience at all with the modules in CANopen or the current implementation (apart from a very rough understanding of the concept)

But Janez, the maintainer of the CANopenNode is usually very familiar with the CiA CANopen standard.
@CANopenNode : Can you contribute anything?

Also @nimrof may have a lot of experience and perhaps a deeper insight into the code concept of the module implementation of the CANopenNodeEditor.

I consider options outside the standard to be critical, as it dilutes the concept of the CANopenEditor and CANNopenNode. I know that Janez has a similar view. This extension could/should be extended in a fork.
A standard-compliant improvement is extremely welcome and would advance this project.

[GRoussos]

Thank you both for the feedback. I have appreciated the CANopenNode project and would be happy and interested to contribute to it. @trojanobelix I think we got carried away a bit in the discussion about modules, @nimrof 's suggestion brought me back to my initial motivation, which is some way to:

1. Maintain (view / edit) different parts of an OD, with one of them being a complete base OD (i.e. with all mandatory objects defined, etc) and the rest being "patches" that will define objects to add, delete or modify in the base OD. Being able to do everything in CANopenEditor which we know and like is our preference
2. Combine the base OD and the patches relevant for each device variant into a single standard-compliant. Eg. product variant X uses the base OD and patches 2,5,6. This needs to be done programmatically, eg. as part of the firmware build process.
3. (related to point 2) During the generation of the product-specific OD, it is useful to be able to set some values, eg. FW/SW version, Product ID, without having to modify any EDS/XDD files.

Modules seem like a reasonably good way to implement point 1 above, though questions still remain. Using modules will allow us to have the base OD and all patches in a single EDS/XDD file, though this is not necessarily useful/preferred. One alternative is to have each patch as a separate XDD/EDS file as in @nimrof 's suggestion. I now think that the latter option is better now, as we don't have to (ab)use modules and we can have separate files for each patch, which is better for version tracking.
To implement points 2 & 3 above I think a custom application leveraging EDSSharp is the best option after all. @nimrof I don't have any experience with protobuffer so I can't say if I would prefer to do the patching in protobuffer form or the "native" internal EDSSharp data structure (assuming there is one), but I will look more into it.

Modules could still be useful in our case for run-time optional OD entries. I am also interested to contribute to CANOpenEditor, modules may be a good area for that, I also have a few other topics in mind to discuss separately.

Thank you both for the feedback and discussion!

[trojanobelix]

I understand your point of view. However, it is often a good approach to use standard implementations as far as possible.

Admittedly, the suggestion was not entirely altruistic:
The current status of module implementation is currently poor and not maintained.

Extensions in this area would bring the project forward. It would be great if you could get involved.

[CANopenNode]

Hello, I'm a little late here, but have some ideas.
I think, recently introduced and still experimental protobuffer database offers a lot of options. CANopenEditor can currently export and import binary protobuffer or equivalent json string. So I suggest the same approach as @nimrof.

Protobuffer or json can be easely used in any language. I prepared an example also for Dokuwiki and JSON Data Plugin. Template and patch is as simple as that:

<json src=DS301_profile display=all>{
  "objects": {
    "1000": {
      "subObjects": {
        "00": {
          "defaultValue": "0x000F0191"
        }
      }
    }
  }
}</json>

I didn't try, but protobuffer's MergeFrom function seems very promising for this purpose. It would be very easy to add it into CANopenEditor. Maybe something similar as in InsertObjects.cs

Unfortunately, with eds or xdd standard database something like this may become very complex.