Latest release: which version of CanOpenNode?

[seclorum]

Hi - its not possible to use the latest version of libedssharp to build CO_OD.? files for use in CanOpenNode.

Some details - version of libedssharp: 5c8f76f 2017-09-11 | Merge branch 'add_memory_regions' of https://github.com/martinwag/libedssharp into martinwag-add_memory_regions [Robin Cornelius] .. produces CO_OD.? files that are incompatible with ..

Version of CANOpenNode:

* 2c5d685 2020-08-11 | Differentiate between SDO_C states so state can be determined in a worker thread when passed a CO_SDOclient_t pointer (#218) (HEAD -> master, origin/master, origin/HEAD) [Miles Simpson]

If anyone has a clue as to which of the latest releases of both projects still work successfully together, I'd love to hear the details. I'm currently blocked on my project because I'm kind of stumped on the synchronicity of the libedsharp libary and the CANOpenNode library versions .. they seem to have diverged somehow. If someone more knowledgeable than me can provide details as to which versions of each project work well together, I'd be very grateful ..

[robincornelius]

Hi.

In preferences you can set which version to export...but the stack is changing quickly and I’m not keeping up with every change.

I’ll try and see later where we are and do an update if needed.

Sent from my iPhone

On 12 Aug 2020, at 15:33, seclorum notifications@github.com wrote:

 Hi - its not possible to use the latest version of libedssharp to build CO_OD.? files for use in CanOpenNode.

Some details - version of libedssharp: 5c8f76f 2017-09-11 | Merge branch 'add_memory_regions' of https://github.com/martinwag/libedssharp into martinwag-add_memory_regions [Robin Cornelius] .. produces CO_OD.? files that are incompatible with ..

Version of CANOpenNode:

• 2c5d685 2020-08-11 | Differentiate between SDO_C states so state can be determined in a worker thread when passed a CO_SDOclient_t pointer (#218) (HEAD -> master, origin/master, origin/HEAD) [Miles Simpson]

If anyone has a clue as to which of the latest releases of both projects still work successfully together, I'd love to hear the details. I'm currently blocked on my project because I'm kind of stumped on the synchronicity of the libedsharp libary and the CANOpenNode library versions .. they seem to have diverged somehow. If someone more knowledgeable than me can provide details as to which versions of each project work well together, I'd be very grateful ..

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[robincornelius]

Yea, more testing may be required.. but i've just tested with the git heads of both projects and it works. if you go to tools->preferences and set it to CANOPENNODE_V2 the example _project.xml in the canopennode/example folder is producing an CO_OD.c/h that is compiling with out error on the latest can openode git

Please try the autobuild https://github.com/robincornelius/libedssharp/raw/gh-pages/build/OpenEDSEditor-latest.zip this us updated every time there is a push to the repository and this contains all the latest updates

[seclorum]

Thanks for the headsup - I downloaded the -latest.zip and now I've tested with the V2 option set and I still run into issues with uncompilable CO_OD.? files being produced .. ./CO_OD.h:120:31: error: duplicate member 'PDO_MappingEntry' UNSIGNED32 PDO_MappingEntry;

Basically today I will spend some time going back through the revisions until I can find a matching CanOpenNode/libedssharp that produces a working Object Dictionary for my project, and I'll report my findings in case its of use for further development/testing ..

[seclorum]

Here is the source EDS file I am using for this effort, in case its of use for further debugging/development .. also, as I am a relative ignoramus to CAN specs (but trying really hard), its possible I'm overlooking something obvious in this EDF that might be confusing libedssharp ..

_test.eds.tar.gz

[robincornelius]

Thanks, i was just going to ask to have a copy of that. I'll take a look with latest git heads and see what happens

On Thu, 13 Aug 2020 at 10:44, seclorum notifications@github.com wrote:

Here is the source EDS file I am using for this effort, in case its of use for further debugging/development .. also, as I am a relative ignoramus to CAN specs (but trying really hard), its possible I'm overlooking something obvious in this EDF that might be confusing libedssharp ..

_test.eds.tar.gz https://github.com/robincornelius/libedssharp/files/5068296/_test.eds.tar.gz

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/robincornelius/libedssharp/issues/223#issuecomment-673377886, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABG2GCYMSICAOTY7JQR5ALSAOYY5ANCNFSM4P4ZHSJA .

[seclorum]

One stupid question, perhaps - when I load the .EDS file in libedssharp (-latest), the document in the listview on the left is highlighted RED - does this indicate a parsing error, or some aspect of validation that libedssharp is not passing with the file? I've tried to work it out by reading the sources, but its a little obtuse ..

[robincornelius]

Oh red means it is not saved, or there are unsaved changes in the main file format (XDD) so if you just load in an eds file its just telling you its unsaved, Possibly not the most helpful thing. In this case. Its more useful when you have a saved file, then edit something, it warns you you have unsaved changes.

I'm having a few issues currently. I'm not sure if its related to your issue or if there is an underlying regression somewhere. But i suddenly can't get a project to build that was working fine myself so debugging that.

On Thu, 13 Aug 2020 at 11:16, seclorum notifications@github.com wrote:

One stupid question, perhaps - when I load the .EDS file in libedssharp (-latest), the document in the listview on the left is highlighted RED - does this indicate a parsing error, or some aspect of validation that libedssharp is not passing with the file? I've tried to work it out by reading the sources, but its a little obtuse ..

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/robincornelius/libedssharp/issues/223#issuecomment-673392542, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABG2GFB2KBENS5KKWMQWUTSAO4OBANCNFSM4P4ZHSJA .

[seclorum]

Okay thanks for the info - wasn't sure if it was relevant, but makes sense now.

In case you would like to have a bit more interaction on the debugging of things, I'm also sitting at my desk trying to work out whats going on - perhaps we could meet on Slack or something somewhere? IRC would also work.

[robincornelius]

Hi, i've created a slack workspace that may be useful for future work. Feel free to join.

https://join.slack.com/t/canopennode/shared_invite/zt-ghjhfg12-qGQNWvSEmhqcSedhFaLpuA

On Thu, 13 Aug 2020 at 11:29, seclorum notifications@github.com wrote:

Okay thanks for the info - wasn't sure if it was relevant, but makes sense now.

In case you would like to have a bit more interaction on the debugging of things, I'm also sitting at my desk trying to work out whats going on - perhaps we could meet on Slack or something somewhere? IRC would also work.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/robincornelius/libedssharp/issues/223#issuecomment-673398389, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABG2GHTDCYUV6EDQVPWYVLSAO6BLANCNFSM4P4ZHSJA .

[seclorum]

Okay, just to tie off this thread a bit .. @robincornelius and I met in Slack and went through some of the issues I have had, which seem to be related to the fact that I am using Lenze Engineer 2.28.0.0 to export the EDS files, and there are some compatibility issues we discovered in this technique, which libedssharp is going to have to be updated in order to fix.

Some notes from the Slack conversation:

• CanOpenNode requires 0x2100 Error status bits (OCTET_STRING) at least 10 bytes
• The object 0x1800 needs to be called "Identity" not "Identity Object" and some of the child objects are named slightly wrong
• PDO Mapping Entries need to be uniquely named
• Event Timer entries don't make sense on Receive PDO's (dunno why Engineer got this wrong, maybe its a bug in the exporter)
• Any VISIBLE_STRINGS in the EDS export actually have to have a value - i.e. can't just be null, best is if they have chars

Continuing on this in the next few days, hopefully @robincornelius can update with more info as he finds it in his next work session .. Thanks again @robincornelius

[robincornelius]

The latest XDD head on git (and the travis-ci build) contains some fixes for the above.

For variables where the name matters because CanOpenNode expects a variable/struct to be named a particular way a test/warning/auto fix is applied to create the correct names, warnings logged. The Record objects it checks if they are all named the same and adds a number suffix to make it unique, warnings logged in editor Any VISIBLE strings with no data will automatically be given a single 'X' character and set to 1 byte to make it compile. Warnings will be logged in editor For the specific combination of OD entries needed to initialize a core canopen node function eg NMT, a check is performed that all the required objects exist. If they don't a warning is given at export time.

On Thu, 13 Aug 2020 at 14:13, seclorum notifications@github.com wrote:

Okay, just to tie off this thread a bit .. @robincornelius https://github.com/robincornelius and I met in Slack and went through some of the issues I have had, which seem to be related to the fact that I am using Lenze Engineer 2.28.0.0 to export the EDS files, and there are some compatibility issues we discovered in this technique, which libedssharp is going to have to be updated in order to fix.

Some notes from the Slack conversation:

• CanOpenNode requires 0x2100 Error status bits (OCTET_STRING) at least 10 bytes
• The object 0x1800 needs to be called "Identity" not "Identity Object" and some of the child objects are named slightly wrong
• PDO Mapping Entries need to be uniquely named
• Event Timer entries don't make sense on Receive PDO's (dunno why Engineer got this wrong, maybe its a bug in the exporter)
• Any VISIBLE_STRINGS in the EDS export actually have to have a value
• i.e. can't just be null, best is if they have chars

Continuing on this in the next few days, hopefully @robincornelius https://github.com/robincornelius can update with more info as he finds it in his next work session .. Thanks again @robincornelius https://github.com/robincornelius

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/robincornelius/libedssharp/issues/223#issuecomment-673470447, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABG2GEPK4VGL767RA7436LSAPRH7ANCNFSM4P4ZHSJA .