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

[Walker34]

The OPC-UA standard recommends a SHA256 secure connection, as do all secure connections in 2023. The Labview OPC-UA Toolkit can only establish a SHA1 (Basic256) connection, which is deprecated.

After my request to NI support, I am told:
"I have received a rely from the proper team and would like to share with you.
They have once again confirmed that there are no plans to introduce new features to this toolkit in the upcoming year.Our R&D department is not currently working on an update to the OPC UA toolkit, so it is unlikely that the Basic256Sha256 security settings will be added to the toolkit.
We are currently only "Sustaining" the LabVIEW OPC UA Toolkit. This means that we no longer update the product, but occasionally update for newer LabVIEW versions."

Shameful. OPC-UA is one of today's important tools. It enables remote monitoring of equipment in a secure, structured way. Every equipment supplier must be, or will have to be in the next few years, capable of providing this functionality. Hearing that NI will no longer be actively developing this product takes away all hope for Labview's future. It's just one of many signs that this IDE is stuck in 2010.

The ship is sinking captain.

[Martin_Henz]

I can agree with you.

[Sebastian.Weber]

My impression is they got this toolkit from somewhere, but have no idea about it. So, they make it availabe for newer LV version, and that's it.

Some years ago, I reported a problem, pointing them to a wireshark capture where it was quite obvious, but their answer was more like "No idea how to fix, don't want to break something". So, no interest in this really important toolkit. It's a shame that they continue this behavior. But hey, at least, we now pay every year for great, new features.

However, the toolkit seems to be kind of a wrapper around the standard OPC UA implementation of unified automation. It might be not that difficult to write an own wrapper - but it costs development license fees.

Some infos about the problem I discovered:

When reading a value from an OPC server, the client sends the max-age in ms as U16. If the value in cache is older than max-age, the server should get a new value from the hardware, and send that. max-age=0x0000 requests a fresh value from hardware. 0xFFFF means "Don't bother, give me what you have in cache".

Labview uses 0xFFFF by default, and there's no way to change this.

Now, a builtin server on a device might always send fresh values from the hardware, but if you use a stand-alone server, which connects to the hardware on it's own, the server might return ancient values on read, maybe even nothing with status "bad not initialized" or similar.

Workaround: Creat a subscription on that value. This causes the server to permanently read data from the hardware and to always have fresh values in cache, but it also causes system load in LV if that value changes often.

I don't see why fixing this is not easy. A simple, optional input at the read VI, and that's it.

(I don't know if this was fixed in the meantime, we are still using an old version.)

[rolfk]

It most likely incorporates the standard source code you can get when you register as an OPC member. And from that most likely the ANSI C Stack source code which the OPC Foundation has discontinued and is not supporting anymore. As such the toolkit itself has been getting unsupportable since the NI developers indeed do not know the actual source code on a deeper level and it is difficult to modify in a significant way existing source code that has been developed by someone else.

In addition the developers who worked on that are most likely not working at NI anymore so there is even limited knowledge about the LabVIEW wrapper interface that was developed by NI.

Most promising solution is likely to write a LabVIEW wrapper for one of the commercially available OPC UA ANSI C stacks such as:

- https://industrial.softing.com/products/opc-ua-sdks.html

- https://opcfoundation.org/products/view/ansi-c-based-opc-ua-server-sdktoolkit/

Somewhat easier for non-hardcore programmers would likely be to use the according .Net stacks which the OPC foundation still has an officially supported implementation that you can download as registered member. And you don't even need to be a Corporate member as even as lowest rank OPC UA Logo member you get access to that. However in order to use these in commercial projects one would need to be registered as a highest tier Corporate Member, which is a pricy yearly membership fee.

Another option might be to develop a LabVIEW wrapper around the open62541 Open Source project. But I'm not sure about the features it supports and it definitely won't be trivial to interface to LabVIEW.

[Andrey_Dmitriev]

---

@Walker34 wrote:

there are no plans to introduce new features to this toolkit in the upcoming year

---

Ups, very very sad. My hope was that NI will implement someday finally "fully supported" standard. There are not only security features missing, but the Methods Calls as well. Within last years the OPC UA was more and more actively used, in our automation world almost all OPC connections was replaced to OPC UA. The standard is not so bad, but implementation of the Wrapper is not so easy, because requires lot of accurate work. In the past I was able to implement OPC UA Client in B&R PLC as well as client and server, based on open62541 (because Methods Calls was strictly required) and it was lot of work, really. In additional, open62541 library was far away from ideal, lot of troubles, some versions aren't working stable, etc. Implementation "from the scratch" based on reference code from OPC Foundation — may me will require much more work. And LabVIEW saved for me lot of work days if not weeks, for simple projects, because works like a charm out of the box, at least the part which was already implemented, except some minor issues with deployment. May be time to go with own open-source wrapper. Without fully-featured OPC UA toolkit NI/Emerson will lost lot of industrial customers.

[Walker34]

---

@rolfk  a écrit :

Most promising solution is likely to write a LabVIEW wrapper for one of the commercially available OPC UA ANSI C stacks such as:

- https://industrial.softing.com/products/opc-ua-sdks.html

- https://opcfoundation.org/products/view/ansi-c-based-opc-ua-server-sdktoolkit/

Somewhat easier for non-hardcore programmers would likely be to use the according .Net stacks which the OPC foundation still has an officially supported implementation that you can download as registered member. And you don't even need to be a Corporate member as even as lowest rank OPC UA Logo member you get access to that. However in order to use these in commercial projects one would need to be registered as a highest tier Corporate Member, which is a pricy yearly membership fee.

Thank you for responding all. I'm glad to hear some people that are disapointed too. 

Yes Rolf, I think your advice is correct : Make a wrapper around a commercial API existing on the market. On my side, I'm looking for something quite easy to integrate, I have already a lot of challenge with the main application. So I'm looking in direction .NET.

Here are my feedbacks after a few tests with Labview 2022:

• I just tried Unified Automation Toolkit. It seems to work well, not very complicated to use. But it is not cheap. 5400euro/seat.
• OPC Foundation. It seems to work well but I found this library very difficult to understand, quite cryptic. Adding a simple node is not trivial. Price unknown (Corporate Member)..
• opcua.traeger.de. Not tested yet. Price attractive. 
• LibUa : Free, open Source, but small community. The .Net build seems to work well, but I'm stuck within Labvew integration. Very promising. Work in progress.

[rolfk]

Just a theoretical question (I have not made any plans in that direction yet and still need to finish two other projects that are almost there but still need some finishing touch).

What would you be willing to pay for a nicely working LabVIEW library based on the open62541 project? Assume a one time fee for a development license with no further runtime license fees and some lower cost upgrade fees when you want to use newly developed features in later releases.

[Martin_Henz]

This (based on open62541) or something similar seems the only way. I was already thinking about something like this. It's a bit much for a single developer and it's not easy. In the past and up to now, I had only a very limited number of projects which using OPC DA (all of them are clients). Some more with OPC UA in tha past view years and all of them are OPC UA servers and all of them are rather simple. I know almost nothing about how customers use the server.

To be more concrete: around 1k euros (less than 2k) would be fine. (A little more bucks than for interesting libraries that I don't need at the moment).

---

[rolfk]

Thanks for that feedback. While I have no illusions about the possibility to paying for the full development cost for such a toolkit, the sum you named would be a reasonable working point, I think.

There are some difficulties with this. I’m not sure about how many not fully working features are in that Open62541 library and it’s almost certainly very hard to impossible to get improvements committed to that project as an outside developer, if one is even able to understand the code base good enough for that. So there is the risk of things not working as desired and having practically no influence whatsoever on that.

Let me think about it over the holidays. I have several motivations to embark on this, one of them being the fact that NI pretty much dropped the ball on any Industrial Communication standard.

OPC UA is one of the easier ones to try to implement for LabVIEW. There are existing libraries to use and the standard is quite commonly in use nowadays, so there is a potential user base.

[Cyril]

Hello Rolf,

Circling back 4 months after this post, I was wondering if you were able to give any more thoughts to this (whether wrapping open62541 or another commercial library, whether c or .NET...).
I would be in need of such a LabVIEW library in a foreseeable future and be willing to collaborate/help in some capacity. I also work in a field and for company where I could probably manage to get some funding if there is significant interest.

If you are still interested in pursuing this,please contact me.

Thanks,