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.