OPC UA Structures or Extension Objects Support

[mohit_agarwal]

Hello,

I am from Atlas Copco and also the editor of VDMA OPC UA 40450-1 and 40451-1 Companion Specification.

We have an OPC UA Server implemented based on the companion specification and also have a public reference implementation for the same in the following link: https://github.com/umati/UA-for-Industrial-Joining-Technologies/tree/main/OPC_UA_Servers/Release2 

One of your customer is using your OPC UA Toolkit but they said that OPC UA Extension Objects are NOT supported.

Are there any plans for the OPC UA Toolkit to support OPC UA 1.05.02 Structures and Array of Structures as it is a BLOCKER for our customer?

[Sebastian.Weber]

The toolkit does not support extension objects, unless they are kind of  "browseable". I don't know exactly the internas of OPC UA, but if the variables inside the object have NodeIDs, the toolkit should be able to use them.

The toolkit also does not support methods, i.e. those entries with pink / blue icons in UA Expert. 

National Instruments does no longer develop the OPC UA toolkit, see here:

https://forums.ni.com/t5/LabVIEW/OPC-UA-Toolkit-is-no-longer-developed-What-a-shame/td-p/4343168

which especially means they do not add new authentication algorithms, which means the OPC UA toolkit does not work with clients / servers requiring newer algorithms. You might also get some ideas about alternatives, there.

Personally, I don't understand this. First, the toolkit seems to be a wrapper around the reference implementation from unified automation, so all that functionality is available, and the development shouldn't be that time consuming.

Second, for me (and others), OPC UA is THE way to communicate with PLCs, because it does not require any programming on PLC side, just switching on the server. I don't know why National Instruments decided to abadon a technology that's widely used in industry, i.e. a sector which is more easy with paying their price.

About your customer:

OPC UA in LabVIEW is quite fiddly. While you can write some demo codes within 2 minutes, it's more complex to get a more robust system, which for example reconnects if the connection is lost.

We are operating a large number of different hardware, also screw drivers from you. Almost all of them come with a simple TCP/IP interface and a more or less complex protocol behind, but usually, it's not that difficult. We prefer this solution, since it's easier to handle e.g. disconnects, and because we avoid license costs for projects without a PLC. (Though, OPC UA is quite cheap)

[mohit_agarwal]

Thanks for your response, Sebastian.

The variable provided in our OPC UA Reference Server is part of the address space, as shown below. Our customer was NOT able to read the variable below, which is of the Custom Structure Data type.

I agree to your point, if the OPC UA Toolkit is using Unified Automation Library in the background, it should work and it is NOT major work for the Toolkit to update it.

If LabView has abandoned OPC UA technology and NOT maitaining it, then they should make it clear and at least the end users will use some other converters or different applications to consume data.

[rolfk]

---

@Sebastian.Weber wrote:

Personally, I don't understand this. First, the toolkit seems to be a wrapper around the reference implementation from unified automation, so all that functionality is available, and the development shouldn't be that time consuming.

Second, for me (and others), OPC UA is THE way to communicate with PLCs, because it does not require any programming on PLC side, just switching on the server. I don't know why National Instruments decided to abandon a technology that's widely used in industry, i.e. a sector which is more easy with paying their price.

---

It's not that surprising. I haven't seen the OPC UA reference implementation but I have little reason to believe that it is fundamentally different than the open62541 library. And that interface is ABSOLUTELY NOT suited to be called directly by LabVIEW since it has a fundamentally different memory management paradigm and data type handling. I have been working on a LabVIEW interface to the open62541 library and it is a serious piece of work. So far I have pretty much all of the client functionality implemented for scalars, 1D Arrays of scalars and Matrices of scalars just as the NI toolkit provides. In addition I even have preliminary support for method calls, as long as the parameters only contain above mentioned scalars and array of scalars. But support for things like structure data, extension objects and server meta data types is an extremely tedious job to get right. I'm slowly getting there but this is a side project, not my daily work, so things go a bit slow.

So yes I understand why the NI toolkit doesn't support structures and other complex datatypes even if the underlaying reference implementation almost certainly supports that. I have been in contact with NI about some support for information about using variants in external code and they seem so far very receptive of that and have indicated strong interest to cooperate. From what I gathered they have recognized that they can't support every technology out there as much as they would like too, since the available resources are limited. They seem to want to focus on the core product of LabVIEW itself and leave much more of the rest to the community wherever possible.