Unknown Warning while saving file or exporting Node

[PascalGuthof]

I have compiled the latest version. Now when saving or exporting a node, a window comes up with a warning that my PDOs are not mappable. The same file was saveable by an older version of the Editor.

The OD exported by nevertheless is compilerable and seems to work.

The only difference I see at first sight is that in OD.h four entries are missing. but I don't know their purpose.

New OD.h:

Old OD.h:

Please don't be surprised, the pictures are from different devices. If you compare the new OD.h and the old OD.h of the same device, exactly the 4 marked entries are different.

[trojanobelix]

Can you provide the xdd file?

Four entries are missing: The CNT_GFC entries (and others) are necessary if you have old eds file, that do not have "CO_countLabel" set. So you might it be using a newer eds file for the test that supports CO_countLabel?

[PascalGuthof]

@trojanobelix Thanks for you reply. I have now tried again to create a variable on a new project and map it. This causes the error just like the project I already tested. As it looks, this is a false warning. The OD I export from the project works as usual.

I have uploaded the file to a file hoster. I hope that's ok.: https://www.mediafire.com/file/jivtx1yv0xxxepr/DS301_profile.xpd/file

[CANopenNode]

The only difference I see at first sight is that in OD.h four entries are missing. but I don't know their purpose.

The "New OD.h" seems to be correct, my (old version) it is the same. The "Old OD.h" is strange anyway.

[trojanobelix]

The warnings come because a t access is expected for an RPDO and an r access for a TDPO. However, Vector's EDS checker is quite happy with the assignment of r to RPDO and t to TPDO. I'll take another look at the whole thing in a larger context. There are some PRs on the subject of PDO access type, but I can't really assess them yet. It depends a lot on whether you define the whole thing from a consumer or producer point of view. p and c might have been the better choice :-).

[trojanobelix]

You should change the Access SDO of 6000, 6002, 6004 to rwr, if it is a TPDO.

[PascalGuthof]

Sorry, I was on holiday until last week.

Thanks for all the feedback and the help!

You should change the Access SDO of 6000, 6002, 6004 to rwr, if it is a TPDO.

I don't know what you mean. I can only set the access to no, ro, wo and rw.

The warnings come because a t access is expected for an RPDO and an r access for a TDPO

Yes I know this point of view from CanOpen for Python. But if I set the access to r for a TPDO, I can't map the TPDO because it just doesn't show up in the mapping tab. But maybe I just don't understand exactly what you mean. I followed the video tutorial from @HamedJafarzadeh and he did it the same way. In the program it worked fine for me.

The only difference I see at first sight is that in OD.h four entries are missing. but I don't know their purpose.

The "New OD.h" seems to be correct, my (old version) it is the same. The "Old OD.h" is strange anyway.

The "Old OD.h" is from a fork of the EDS editor. This was also from @HamedJafarzadeh. Maybe there was a bug in his version, but even with that my program worked almost fine.

[CANopenNode]

I also get the same warnings when I export https://github.com/CANopenNode/CANopenDemo/blob/master/demo/demoDevice.xdd to OD.h/c V4 files.

The warnings come because a t access is expected for an RPDO and an r access for a TDPO.

We have to clarify this. I was using t for TPDO and r for RPDO. Please see commit https://github.com/CANopenNode/CANopenEditor/commit/26a11e14c58512e9e5f8e2818dfe34900a8a395d

There is only a misplaced warning, generated code seems to be correct.

[PascalGuthof]

I also get the same warnings when I export https://github.com/CANopenNode/CANopenDemo/blob/master/demo/demoDevice.xdd to OD.h/c V4 files.

The warnings come because a t access is expected for an RPDO and an r access for a TDPO.

We have to clarify this. I was using t for TPDO and r for RPDO. Please see commit 26a11e1

There is only a misplaced warning, generated code seems to be correct.

Thanks for checking and the effort. Then I can ignore the warning. That helps me a lot.

[trojanobelix]

Reopened for tracking. It is still an open issue.

[trojanobelix]

should be fixed in a43e0a84622fe4e30a5cd86c12d6c7858a8260f2

Test and feedback would be much appreciated

[trojanobelix]

Will be closed in a few days due to lack of feedback