OPC-UA Toolkit is no longer developed. What a shame.

[rolfk]

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.

[Andrey_Dmitriev]

---

@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).

[rolfk]

---

@rolfk wrote:

My setup is:

Visual Studio 14, 2015 Community

CMake 3.29.1

Python 3.12.2

OpenSSL 3.0.13

open62541 (latest github master)

---

CMake 3.29.2 fixes the issue with referencing the wrong path for finding 32-bit OpenSSL libraries.

[Quiztus2]

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.

[Andrey_Dmitriev]

---

@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...

[rolfk]

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.

[Andrey_Dmitriev]

---

@rolfk wrote:

Well, you need to run CMake and create a new build configuration for 32-bit into a different build folder.

---

OK, thank you, got it. I was sure (and wrong in my understanding) that this configuration is exists already "out of the box". In theory can be added directly in Visual Studio, or may be more simple with CMake. Now its clear for me.