LabVIEW
OPC-UA Toolkit is no longer developed. What a shame.
I did indeed give it some more thoughts and even downloaded the open62541 code to compile a DLL from it. However the open62541 API is not very suitable to directly interface to from LabVIEW. So I was attempting to create a wrapper in C that makes the API more LabVIEW friendly. It's still in its early stages and doesn't really work yet. For this I started with the client API and think it will be fairly doable but haven't really looked into the server API yet. Basic data item access for scalars as a client is probably feasible with a few more days of development time. More complex data type support could quickly end up in a lot of extra work.
I'm slowly getting there but compiling the open62541 library on Windows is far from being an easy walk in the garden. Getting everything installed correctly such as Cmake, Python3, OpenSSL and such which are all fairly essential requirements, making some adjustments to the library source code itself and some of the tools (the current installation won't recognize Python 3 higher than 3.08 out of the box, the Cmake OpenSSL detection scripts don't work with some of the common OpenSSL installers out there out of the box either and some open62541 source files have minor problems to compile under Windows), it takes all quite a bit of time to even get the library itself compiled properly.
Next step is to get the wrapper running to call the library functions. That's going to be also a few more days at least and that is outside of my normal work.
Try out vcpkg for dependencies. It's a game changer for dependencies on windows. It took me sometimes days to build dependencies. With vcpkg this time is reduced to minutes.
@rolfk wrote:
the current installation won't recognize Python 3 higher than 3.08 out of the box
That is strange, I just checked with following setup using all latest available versions:
Visual Studio Professional 2022 v.17.9.6 (released today)
CMake 3.29.1 (released 3rd April)
Python 3.12.3 (released today)
open62541 v.1.4.0 (released yesterday)
And it was builded without significant problems (following instructions). Screenrecording in the attachment. Just for fun I have compiled "Client Example" and checked if this can be connected to the Server from OPC UA Toolkit. Yes, it seems to be OK:
I can share my fork with all intermediate files including \build folder (but I have seen that there are lot of path hard coded after CMake, so it will work only from directory where it was produced as shown on the video).
Well, I'm working directly with code from my github repository which is a 100% clone from the official open62541 github repository. So not sure why your system would be different. Did you download some preconfigured source code release file?
The according script in the tools/cmake/FindPython/Support.cmake definitely does only contain versions up to 3.8. Once I added additional versions up to 3.12 to that list Cmake was happy to find my Python installation.
Another issue is using OpenSSL from the ShiningLight website. The Cmake scripts want to find the installed libraries in the x32 subdirectory for 32-bit, which I find weird as that is usually written as x86 which is also what the installer from the ShiningLight website uses.
My setup is:
Visual Studio 14, 2015 Community
CMake 3.29.1
Python 3.12.2
OpenSSL 3.0.13
open62541 (latest github master)
@rolfk wrote:
Well, I'm working directly with code from my github repository which is a 100% clone from the official open62541 github repository. So not sure why your system would be different. Did you download some preconfigured source code release file?
No, everything "from the scratch" and out of the box. Latest snapshot from master branch. By the way, attempt to build this on my work PC (with almost same setup, the only major difference that this is Win10 and not Win11) was failed with following message:
Internet told me that probably Path Variable is too long (yes, I have much more other software installed). But once built on the "functional" PC I can use VS Solution also on my work PC. Usually for such projects with many dependencies I preparing Virtual Machine to avoid such investigations journeys in the future. I haven't install SSL libraries at all.
Anyway, I also compiled Server Example from open62541 and connect to it from LabVIEW with OPC UA Toolkit, this works as well:
So sad, I have not so much time to play with this. If you will moving forward, please please add Methods Calls — this is what I really would like to have on LabVIEW's side and this feature is missing in NI OPC UA Toolkit.
Method calls are definitely on my wish-list once I got connection handling and scalar variable read and write working nicely. But that is still a bit in the future. In terms of dependencies, the open62541 library is not even that bad. Cmake and Python are only needed for the generation of the build projects. OpenSSL and/or mbedTLS are crucial to allow any form of encryption support. OPC UA without support for encryption is only an option on a fully isolated network.
But I may have found a possible reason for the error in finding Python from the default open62541 sources. I did not do the "Python six package" installation. Funnily, that Python six package seems to be not really needed as everything seems to work fine once I changed the cmake script to search for the correct version.
Now getting examples and some of the tools to compile when choosing to create a shared library under Windows is going to be the next challenge. Building a shared library, especially on Windows, seems to be an undertested feature of this library. 😀
Also, OpenSSL can be used for certification and encryption handling on the standard client and server, but the pubsub side of things (which is still highly in development at this point) only supports mbedTLS at the moment.
@Andrey_Dmitriev wrote:
@rolfk wrote:
Method calls are definitely on my wish-list once I got connection handling and scalar variable read and write working nicely. But that is still a bit in the future. In terms of dependencies, the open62541 library is not even that bad. Cmake and Python are only needed for the generation of the build projects. OpenSSL and/or mbedTLS are crucial to allow any form of encryption support. OPC UA without support for encryption is only an option on a fully isolated network.
But I may have found a possible reason for the error in finding Python from the default open62541 sources. I did not do the "Python six package" installation. Funnily, that Python six package seems to be not really needed as everything seems to work fine once I changed the cmake script to search for the correct version.
Now getting examples and some of the tools to compile when choosing to create a shared library under Windows is going to be the next challenge. Building a shared library, especially on Windows, seems to be an undertested feature of this library. 😀
Also, OpenSSL can be used for certification and encryption handling on the standard client and server, but the pubsub side of things (which is still highly in development at this point) only supports mbedTLS at the moment.
Yes, "pip install six" was the first command immediately after Python't installation, unfortunately I didn't included this into screen recording - this might save a little bit your time.
I played with open62541 long time (years) ago and in that time got some troubles with compiling with SSL, that was simply turned off somewhere in the headers, because it was "fully isolated use case". And I don't used this with LabVIEW, that was a C++ based service used for communication with B&R PLC.
About shared library the manual stated "open62541 is small enough that most users will want to statically link the library into their programs. If a shared library (.dll, .so) is required, this can be enabled in CMake with the BUILD_SHARED_LIBS option. Note that this option modifies the ua_config.h file that is also included in open62541.h for the single-file distribution.". Personally I don't see significant issues with static link, it looks like NI does this in that way with ni_opcua.dll, but I don't know which framework/library behind of NI's OPC UA implementation, or it was really developed "from the scratch" without using third-party libraries.
Well, the static linking is kind of problematic in terms of the license of the open62541 library. It does allow for a bit of leeway as the MPL is not as contagious as the GPL. But another possible advantage of using a shared library version of the library is that it is much easier to replace the open62541 part with a new fixed version, since it is still highly under development. The LabVIEW wrapper is likely less variable once it works. Of course, due to the under development status of the open62541 it is not guaranteed that a new version would provide the same binary interface, so replacing it with a new version may still require a recompiled wrapper as well.
The NI OPC UA library is most likely based on the standard OPC UA library source code that paying OPC members get access to, just as was the case for the OPC DA implementation. And NI is a member of the OPC standard organization for a long time. The open62541 library was at the time NI released their OPC UA Toolkit still in a preliminary state that would never have allowed to support all the Toolkit functionality.
@Andrey you built the latest version of open62541 and how did you then interface that dll?
Is this your own wrapper on the screenshot? Do you have interest in sharing it?
