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

Datatype information is being lost #149

Open
Blabzillaweasel opened this issue Nov 25, 2024 · 3 comments
Open

Datatype information is being lost #149

Blabzillaweasel opened this issue Nov 25, 2024 · 3 comments
Labels
📭 needs: author feedback More info/confirmation awaited from OP; issues typically get closed after 30 days of inactivity

Comments

@Blabzillaweasel
Copy link

Blabzillaweasel commented Nov 25, 2024

Hi there,

I have been using this software to convert .EDS to .XDD for use in another piece of software called KickDrive Zero, I have found this software requires using the "CANopen XDD V1.0, old" filetype when exporting.

I have noticed that when exporting using this filetype that a large number of entries lose their datatype information.

It does not seem to make a difference whether CANOPENNODE_V4 or CANOPENNODE_LEGACY is used as the exporter.

For example:

EDS:

[1003sub0]
ParameterName=Number of Errors
ObjectType=0x7
DataType=0x0005
AccessType=rw
DefaultValue=0
PDOMapping=0

.XDD (V1.0):

      <parameter uniqueID="UID_PARAM_100300" access="readWrite">
        <label lang="en">Number of Errors</label>
        <description lang="en"></description>
        <denotation>
          <label lang="en"></label>
        </denotation>
        <defaultValue value="0" />
      </parameter>
            <CANopenSubObject edseditor_extension_notifyonchange="false" subIndex="0000" name="Number of Errors" objectType="7" dataType="0000" lowLimit="" highLimit="" accessType="rw" actualValue="" denotation="" PDOmapping="no" uniqueIDRef="UID_PARAM_100300" />```


@nimrof
Copy link
Collaborator

nimrof commented Nov 26, 2024

Hi there,

I have been using this software to convert .EDS to .XDD for use in another piece of software called KickDrive Zero, I have found this software requires using the "CANopen XDD V1.0, old" filetype when exporting.

cool

I have noticed that when exporting using this filetype that a large number of entries lose their datatype information.

That is very likely, the conversion is far from perfect

It does not seem to make a difference whether CANOPENNODE_V4 or CANOPENNODE_LEGACY is used as the exporter.

The CanOpenNode option mostly affects the result of the c-code exporters so that makes sense

For example:

EDS:

[1003sub0]
ParameterName=Number of Errors
ObjectType=0x7
DataType=0x0005
AccessType=rw
DefaultValue=0
PDOMapping=0

.XDD (V1.0):

      <parameter uniqueID="UID_PARAM_100300" access="readWrite">
        <label lang="en">Number of Errors</label>
        <description lang="en"></description>
        <denotation>
          <label lang="en"></label>
        </denotation>
        <defaultValue value="0" />
      </parameter>
            <CANopenSubObject edseditor_extension_notifyonchange="false" subIndex="0000" name="Number of Errors" objectType="7" dataType="0000" lowLimit="" highLimit="" accessType="rw" actualValue="" denotation="" PDOmapping="no" uniqueIDRef="UID_PARAM_100300" />```

Do you have a EDS file with the problem you could share so we could use it to test & fix the problem?

@Blabzillaweasel
Copy link
Author

Please see attached .EDS
example.zip

@CANopenNode
Copy link
Owner

This was recently fixed with #147

Please use the latest release.

@trojanobelix trojanobelix added the 📭 needs: author feedback More info/confirmation awaited from OP; issues typically get closed after 30 days of inactivity label Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
📭 needs: author feedback More info/confirmation awaited from OP; issues typically get closed after 30 days of inactivity
Projects
None yet
Development

No branches or pull requests

4 participants