Labview OPC UA Toolkit and ExtensionObject (custom data types)

[J.Willems]

Hey Rolf,

Yes it is the methods that they are using to get the communication done. 

And it is mentioned that this is not supported in the toolbox. So you tell that it is with only basic data types. 
As inputs for the object it is Uin16 and Uint64.

Feedback is the Uint8, Array of Uint8, String and Base45 String (dont know what that string is).

Dont know what your library supports.

Best regards

Joris

[rolfk]

A slight misunderstanding: OPC UA methods is a different OPC UA service, that is not supported at all by the NI toolkit.

In my toolkit I did implement it but haven't gotten around to test it with more than basic datatypes. The interface uses variants and in that way should allow for any arbitrary datatype to be passed to a method and returned back from it. But that needs more testing before I'm going to claim it really works. And it is at the moment fairly at the end of a list of things to do. I first want to get the installer packaging right, and do more testing for the basic IO node read and write functionality. I also need to do a bit more work for user friendly certificate handling.

Also for input parameters there is kind of disconnect. The translation from LabVIEW variants to OPC UA data elements is simply done in a straightforward way. There is currently no way to easily parse and discover what your input parameter should be build like to be compatible to what the OPC UA server expects. So if the datatype passed to the variant corresponds with the datatype expected by the server, things would go ok, provided my variant translation code doesn't still have some bugs or limitations. But if it doesn't, you would only get a generic error back from the server that there was a datatype error which is not very helpful for many users.

The return of the data is a bit easier. The routine will convert whatever it receives from the server into a LabVIEW variant and you can look at the type in a variant control to build a compatible LabVIEW datatype to Unflatten the Variant into or create dynamic variant parsing code using either the OpenG or NI variant parsing routines.

And Base45 strings I haven't come across yet, neither in the OPC UA libraries nor anything else I ever encountered. But I see that it is a somewhat uncommon encoding similar to Base64, but with a different mapping and more limited character range. https://dencode.com/string/base45

I don't think I'm going to bother with that in my library. Should be easy enough to treat it as a String or ByteString and then have the user do whatever encoding conversion they want.

[T.]

Hi,
We are also looking for an OPC UA client that can read more complex structures. We are currently using the OPC UA Toolkit from NI. However, our customer will be adapting the structure of the OPC UA server for the next project so that the server also contains arrays from structures. Unfortunately, this is not possible with the OPC UA Toolkit. So we are looking for a way to implement this elsewhere with LabVIEW. We are grateful for any tips 😉
You wrote that you use the “open62541 library.” Do you use it with LabVIEW? If so, could you send me an example?
Many thanks,
Tobias

[J.Willems]

Hi T, 

I have been looking into this when I had my issue and after some talks there was decided to use the Python code for the OPC UA command to get the data.

This code was first tested in the Python and then I added a python node to access is. I did use the LV2025Q1 since there the Python3.12 is supported.

Don't know if that is any help for you.

Best regards