Loading / saving descriptions

[dthoeni]

The description for Fields does not seem to be exported into the eds file.
Also if the eds file has descriptions defined, they wont be loaded.

[1000] ParameterName=Device Type ObjectType=0x7 DataType=0x0007 AccessType=ro DefaultValue=0x00000000 PDOMapping=0 Description=The type of the device

[nimrof]

Hi @dthoeni,
I might be missing something here, but isn't Description only allowed in the [FileInfo] section?
There should not be a description in under object as far as i know

Snippet from 306

[dthoeni]

You are right. The CiA Standard does not define this field.

But I think it's allowed to include "custom" fields.

[nimrof]

Ahh,

But I think it's allowed to include "custom" fields.

I found this text that i think is where the idea comes from.

But it also says the the Conformance Tool will give a warning if that is found and that is very likely why it is not written to file.

I am guessing the reason why it is not read is that its not in the standard and we mostly try to follow the standard.

Do you know if Description is widely used "standard" by some big companies?

[dthoeni]

No. I dont know about any company using this.

We'll switch to exchanging xdd files internally from now on, because we lose important information with the eds files.
Sometimes we need to have the description, to know how the data has to look like or what values are valid.

But since eds is quite important and more commonly used we still have problems exchanging these files with other developers.
We have to get them additional information seperatly instead of having it all together in one place.

[nimrof]

Thanks for the extra information about the problem, that explains a lot.

Could something like this work?
It basically prints the description as a comment before the object

;The type of the device
;with
;many lines 
;supported
[1000]
ParameterName=Device Type
ObjectType=0x7
DataType=0x0007
AccessType=ro
DefaultValue=0x00000000
PDOMapping=0

[dthoeni]

If OpenEdsEditor recognizes this as "Description" and displays it accordingly, that would be sufficient.

But I'd say, eventhough this would keep the file CiA standard compliant, it's not a very elegant solution. It's not obvious, that this comment is the description of the field. It's ambiguous.
Exising files, could use this type of comments as sort of a "header" for their object groups. That would mean the header would be associated as description of the first field, which could cause issues.

But long story short.
This is a shortcoming of the eds standard.

I suppose closing this issue, and I'll try to push usage of the xdd.

[nimrof]

But I'd say, eventhough this would keep the file CiA standard compliant, it's not a very elegant solution. It's not obvious, that this comment is the description of the field. It's ambiguous. Exising files, could use this type of comments as sort of a "header" for their object groups. That would mean the header would be associated as description of the first field, which could cause issues.

Yeah, its not a perfect solution, but its the best i got.

But long story short. This is a shortcoming of the eds standard.

👍

I suppose closing this issue, and I'll try to push usage of the xdd.

Sounds good.
Just a idea, if this is for internal use only it might be a idea to use the protobuffer fileformat if you do not need to use a standard file formats

[trojanobelix]

Comment are well defined for EDS in DSP 306:

4.5.4 Comments
Comments can be added to the EDS by using the Comments section. This section has
only entries determining the line number and the line contents.
Lines - number of commentlines (Unsigned16)
Line - one line of comment (max 249 characters). The number is
decimal coded.
Example:
[Comments]
Lines=3
Line1=|-------------|
Line2=| Don’t panic |
Line3=|-------

------|

Perhaps it would be better to choose this format!?

[nimrof]

Perhaps it would be better to choose this format!?

Might have misread, but i interpreted it as there can only be one [comments] sections and we need multiple.

[CANopenNode]

For now I suggest using xdd format. It stores all and is also meant to be a project file for CANopenEditor. EDS does not store descriptions, labels and some custom fields (CANopenNode specific). I think, "extending" eds (standard 306) is not a good idea.

As suggested by @nimrof, protobuffer fileformat may also be an option. Format is similar to JSON and also contains all the information, necessary to import/export standard eds/xdd/other formats. It may be much simpler than xdd format and will become a base for internal data inside CANopenEditor. Experimental import/export to protobuffer is available.

[trojanobelix]

@nimrof No, you are right. I think I missed something:

4.1 Basic Structure
"(...)You can include comments and empty lines in EDS files. You must begin each line of a comment with a semicolon (;). It must be in the leftmost column. (...)"