LabVIEW
OPC-UA Toolkit is no longer developed. What a shame.
From what I understand, he built the server component for the open62541 library, which is a simple command line exe and interfaced to it with the normal LabVIEW OPC UA library from NI. That wrapper you see in the image is from the LabVIEW Toolkit and still interfaces to the niopcua.dll.
@Quiztus2 wrote:
@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?
Yes, I just built open62541 from sources and then tested examples (simple Server/Client) together with NI OPC US (using NI OPC UA Server with open62541 client and visa versa). It works (as expected). I also compiled open62541 as stand alone DLL for dynamic link as suggested by Rolf and created simple wrapper (using NI CVI) with just Connect/Disconnect functions. Last weekend I installed latest B&R Automation Studio (because here is my "reference OPC UA Server as long as we using B&R PLCs) and checked which security policies are supported here:
But I didn't check yet Sha256, this is my plan for next weekend if time permit. After that I'll share everything (currently its too early, because I have the only two SubVIs - Connect and Disconnect).
I can verify that Win10 x64 dll build worked for me out of the box.
@rolfk I could offer myself to help with the wrapper. I can do c++ or setup some LabVIEW tests, since I am familiar with the call library node.
@rolfk wrote:
CMake 3.29.2 fixes the issue with referencing the wrong path for finding 32-bit OpenSSL libraries.
Rolf, sorry for my stupid question, but can you please explain shortly how did you get 32-bit DLL builded?
I set this flag FORCE_32BIT to ON:
option(UA_FORCE_32BIT "Force compilation as 32-bit executable" OFF)
But still have the only 64-bit in the generated by CMake VS solution and projects:
Did I miss something else (sorry haven't not much experience with CMake, and still learning), may be in command line arguments?
Of course, I can create 32-bit in configuration manually, but this is amount of work, which CMake should do for me, isn't?
32-bit is slightly out of the scope for me, but I'm just curious...
Well, you need to run CMake and create a new build configuration for 32-bit into a different build folder. Yes it's a bit of a pain and Visual Studio of course supports mixed 32/64-bit projects, which I use always for my own, usually a lot simpler, projects (well not necessarily simpler in the amount of code, but I seldom have more than one or two project files in my solution). The CMake toolchain as setup by Open62541 does not support that and with so many subprojects in the solution file, it is a pain in the ass to add a 32-bit target for each of them after the fact, aside from the manual adaptions you would have to do for compile and linker settings in each project.
When creating this new build target in CMake, you select the architecture (ARM, ARM64, Win32, x64) to use, together with the type of development environment. CMake does not support to use two or more generators in the same command, and the bitness of the build is part of the generator configuration.
@PincoG wrote:
Hi Rolf,
did you already developed a product around it?
I'm still busy. I got a very experimental Client interface working but am still fighting with the Data Read and Write interface. LabVIEW is extremely strict typed as far as your Diagram Code goes. The only datatype that allows dynamic interfacing is the Variant but that is not documented anywhere how to interface from C Code. That means I need to implement specific VIs for every single datatype I want to support, starting from bytes, words, longs, quads, and the unsigned variants of them, booleans, floating point in single and double precision, timestamps and strings. And then 1-dimensional arrays of them and 2-dimensional ones of all of them too. And that still won't support compound datatypes like structures!! Handling all of that on the C side to convert to and from the Open62541 data type system is highly complex and error prone. I tried several different approaches, the first few were relatively simple but extremely inefficient, then I ventured into trying to maybe figure out how LabVIEW Variants work on the C side of things, but I had to conclude that the almost complete lack of official documentation makes that an exercise in vain.
Currently I'm busy implementing a new approach that should work fine for most datatypes except structures/clusters and at the same time be pretty performant too, but the C side of things gets rather complicated that way. I'm close to have the scalar datatypes working and then need a little more time to get the 1D types working reliable. Once 1D works too, 2D is a relatively simple addition, mainly adding according accessor VIs on the LabVIEW side.
