I am implementing a small C++ Wrapper API for openPOWERLINK v2.7.1 and could not find a documentation which points out the difference between oplk_linkObject and oplk_linkProcessImageObject.
Can someone confirm following theory.
1) I have the option to use oplk_linkObject to directly link application variables to an entry of the OD. The values of the variable are syncronized by calling oplk_exchangeAppPdoIn and oplk_exchangeAppPdoOut.
2) The second option is to allocate a process image and link the OD entries with oplk_linkProcessImageObject. By calling oplk_exchangeProcessImageIn and oplk_exchangeProcessImageOut, the values in the process image are syncronised.
In case that I understood this, why does the second option exist? Is it more efficient compared to the first option? Are there use-cases for the second option, which can not easily implemented with the first option?
Best regards,
Johannes
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For a C++ API wrapper, you can refer to the openpowerlink Qt APP here. It uses a C++ wrapper and APIs as abstraction class, which can be extended (inherited) for applications. In this demo, the application is written in Qt. Note that the documentation has to be generated once you clone the repo.
With regards to the linkObject APIs, you can fine the documentation here.
But to simplify, it is better to go with the processimage.c functions for PI related operations. The seemingly redundant PI functions defined in generic.c are there to provide a more direct control to the user and are not always necessary. In this case, the oplk_allocProcessImage just allocates a block of memory and stores the address pointers to them. With oplk_linkProcessImageObject app can link any object (from OD) with the allocate PI.
The oplk_linkProcessImageObject function uses oplk_linkObject internally and is there to make it convenient(by taking care of direction in/out, PI address pointer) for the app to link to the previously allocated PI . The primary purpose of oplk_linkObject is to allow app to link any OD object irrespective of whether it is part of PI.
Same goes for oplk_exchangeAppPdo* and oplk_exchangeProcessImage* APIs. These both call the same PDO module API internally.
thank you very much for the fast and detailed answer. As the C++ Wrapper is for the microkernel OS Genode, I am going to use oplk_linkObject to better reflect the OS-related coding paradigms.
Best regards,
Johannes
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Glad to be of help. Let me know if you need any support.
Just as a note (may be it will help you ahead), I understand your point of view in using the linkObject API for consistency; do take care of consistent PI pointer management and data copying since the non-PI APIs do not provide it inherently.
Hello,
I am implementing a small C++ Wrapper API for openPOWERLINK v2.7.1 and could not find a documentation which points out the difference between
oplk_linkObjectandoplk_linkProcessImageObject.Can someone confirm following theory.
1) I have the option to use
oplk_linkObjectto directly link application variables to an entry of the OD. The values of the variable are syncronized by callingoplk_exchangeAppPdoInandoplk_exchangeAppPdoOut.2) The second option is to allocate a process image and link the OD entries with
oplk_linkProcessImageObject. By callingoplk_exchangeProcessImageInandoplk_exchangeProcessImageOut, the values in the process image are syncronised.In case that I understood this, why does the second option exist? Is it more efficient compared to the first option? Are there use-cases for the second option, which can not easily implemented with the first option?
Best regards,
Johannes
Hi Johannes,
For a C++ API wrapper, you can refer to the openpowerlink Qt APP here. It uses a C++ wrapper and APIs as abstraction class, which can be extended (inherited) for applications. In this demo, the application is written in Qt. Note that the documentation has to be generated once you clone the repo.
With regards to the
linkObjectAPIs, you can fine the documentation here.But to simplify, it is better to go with the
processimage.cfunctions for PI related operations. The seemingly redundant PI functions defined ingeneric.care there to provide a more direct control to the user and are not always necessary. In this case, theoplk_allocProcessImagejust allocates a block of memory and stores the address pointers to them. Withoplk_linkProcessImageObjectapp can link any object (from OD) with the allocate PI.The
oplk_linkProcessImageObjectfunction usesoplk_linkObjectinternally and is there to make it convenient(by taking care of direction in/out, PI address pointer) for the app to link to the previously allocated PI . The primary purpose ofoplk_linkObjectis to allow app to link any OD object irrespective of whether it is part of PI.Same goes for
oplk_exchangeAppPdo*andoplk_exchangeProcessImage*APIs. These both call the same PDO module API internally.Hope this helps with your development. Thanks.
Best Regards,
#aeicoriiotteam
Hi,
thank you very much for the fast and detailed answer. As the C++ Wrapper is for the microkernel OS Genode, I am going to use
oplk_linkObjectto better reflect the OS-related coding paradigms.Best regards,
Johannes
Hi Johannes,
Glad to be of help. Let me know if you need any support.
Just as a note (may be it will help you ahead), I understand your point of view in using the
linkObjectAPI for consistency; do take care of consistent PI pointer management and data copying since the non-PI APIs do not provide it inherently.Best Regards,
#aeicoriiotteam