OPC UA communication

[Gepponline]

Hi,

  are there any toolkit or examples for OPC UA without using the official NI OPC UA Toolkit? 
I have a couple of applications using OPC UA and to avoid a 300€/y suscription licence I had to use python to communicate via OPC UA.
I'm using LV2017 with no python functionalities so I developed a python service and used a simple text file to exchange data with labview, but now I'm looking for asomething faster than a consinuous file reading. Any ideas?
thank you so much
 

[Rolf Kalbermatter]

On 4/29/2024 at 11:56 AM, Gepponline said:

Hi,

  are there any toolkit or examples for OPC UA without using the official NI OPC UA Toolkit? 
I have a couple of applications using OPC UA and to avoid a 300€/y suscription licence I had to use python to communicate via OPC UA.
I'm using LV2017 with no python functionalities so I developed a python service and used a simple text file to exchange data with labview, but now I'm looking for asomething faster than a consinuous file reading. Any ideas?
thank you so much

I am actually working on it but it is a bit more involved than I had anticipated at first. There is a certain impedance mismatch between what a library like open62541 offers as interface, and what LabVIEW needs to be able to properly interface to. I can currently connect to a server and query the available nodes, but querying the node values is quite a bit of work to adapt the strict LabVIEW type system to a more dynamic data type interface like what OPC UA offers. More advanced things like publish-subscribe are an even more involved thing to solve in a LabVIEW friendly way.

And I haven't even started interfacing to the server side of of the library!

[LogMAN]

I've been using OPC UA SDK for .NET - TRAEGER Docs which requires a developers license (one time or perpetual if you want updates) and is based on .NET

They do have a GitHub repo with an OPC UA client example for LabVIEW --> opcuanet-samples/lv/Basic/Client at master · Traeger-GmbH/opcuanet-samples (github.com)

For my project I implemented the server in .NET and utilize event callbacks and objects to pass data from/to the node manager. This works very well if you are familiar with the common pitfalls of calling external code in LV...

Also looked at OPCFoundation/UA-.NETStandard: OPC Unified Architecture .NET Standard (github.com) which is free if you are a member of the OPC Foundation and OPCFoundation/UA-ModelCompiler: ModelCompiler converts XML files into C# and ANSI C (github.com) which is a code generator that turns XML Node Sets into C# / C code. Haven't worked much with it as my current solution works like a charm 🤷‍♂️

On 4/29/2024 at 11:56 AM, Gepponline said:

I'm using LV2017 with no python functionalities so I developed a python service and used a simple text file to exchange data with labview, but now I'm looking for asomething faster than a consinuous file reading. Any ideas?

Have you considered upgrading?

There is also OpenG LabPython Library Toolkit for LabVIEW - Download - VIPM by JKI. IIRC it required a license and I'm not sure if it works with Python 3 and newer versions of LabVIEW.

[Rolf Kalbermatter]

2 hours ago, LogMAN said:

There is also OpenG LabPython Library Toolkit for LabVIEW - Download - VIPM by JKI. IIRC it required a license and I'm not sure if it works with Python 3 and newer versions of LabVIEW.

It's Open Source (on SourceForge) and I started developping it more than 25 years ago. There never was any license involved but yes at that time Python 2.2 or thereabout was the actual version. I did some updates to also make it work in 2.3 and 2.5 and minor attempts to support 2.7 but had at that time lost interest in tinkering with it as I was getting more involved with Lua for LabVIEW and two scripting solutions next to each other seemed a bit excessive to work with.

The shared library necessary to interface Python with LabVIEW definitely won't work out of the box with Python 3. There were simply to many changes with Python 3 to the internals as well as datatype system that that could work without some changes to the shared library interface code (the change to Unicode strings instead of ASCII is only one of them, but quite far reaching one). Also there is absolutely no support present for Python environments such as offered by Anaconda and the like.

The main reason for starting with LabPython was actually that I had been trying to reverse engineer the script host interface that LabVIEW had introduced to interface to HiQ, and later Matlab. When searching for an existing scripting language that had an embedding interface to integrate into other applications to use as a test case, I came across a project called Python, that was still somewhat obscure at that time. I didn't particularly like Python, and that its inventor Guido van Rossum was actually Dutch did not affect my choice. And when reaching out to the Python community about how to embed Python in another application, I was frankly told that while there was an embedding API available in Python, there was little to no interest in supporting that and I was pretty much on my own trying to use that. It still seemed the most promising option as it was Open Source and had actually a real embedding API. I did not even come across Lua at that time, although before version 5.0 Lua had anyways fairly limited capabilities to integrate it in other applications.

So I developed a Python script server for that interface to allow integration of Python, and even got help from someone from inside NI who was so friendly to give me the function prototype declarations that such an interface needed to support in order for LabVIEW to recognize the server and not crash when trying to load it. After it was done and started to work, I was less than thrilled by the fact that the script was actually a compile time resource, so could not be altered by the user of a LabVIEW application but only by its developer. As more of an afterthought, I added a programmatic interface to the already existing shared library and the main functionality of LabPython was born.

As those old LabVIEW script nodes have been depreciated several years ago by NI, it would be definitely not a wise choice to try to build anything new based on that tech. Not even sure if LabVIEW 2023 and newer even would allow LabPython to be loaded as a script server. But its programmatic interface should be still usable, although for quite a few reasons not with Python 3 without some serious tinkering in the C code of the shared library interface.

Edited May 3 by Rolf Kalbermatter

[Gepponline]

1 hour ago, LogMAN said:

 

Have you considered upgrading?

 

yes, but ABSOLUTELY NOT!
Really too expensive for my single user licence for few internal projects per year, so I decided to stop even the SSP renewal and stay with my perpetual licence.
Maybe I have even the 2020 but all of my projects around the factory are with 2017, no need to upgrade since now...
 

Edited May 3 by Gepponline