Hello,
We have fixed the problem - thank you for reporting it! The updated QuickOPC 2020.2 build is on our Web site.

Please download the current version from www.opclabs.com/products/quickopc/downloads and install it, verifying (on the 1st page of the setup wizard) that it reports itself as 5.58.184.1 or later, and then rebuild your project with the new assemblies and retest.

Does your license cover version 2020.2?

Best regards

Yes, that's what I was trying to say. The Live Mapping currently "ends" at the level of an OPC UA node/attribute. So you, can map UA objects to C# objects, and UA variables (or properties) to C# properties (usually), with lots of flexibility. But the Live Mapping does not currently allow you extend the mapping into the values, if they are structured. It still works, but what gets mapped is the UAGenericData, and you create or access it in the same way as you would in normal procedural code.

Some servers expose the same information in two ways - an object object has variables, but at the same type, it is represented with a data type (structure) on its "root" node. The clients can then choose whether to access the variable individually, or the whole object as a structure. In case of many sub-variables, transferring the structure is more efficient. The structure value can also be read/written/subscribed to atomically - so you work with a consistent snapshot of variables at one point in time (which is sometimes required, but at other times it's not desired - such as when you want to modify just one variable and there are other actors that should be allowed to modify different variables in the same object concurrently). So, it all depends...

Best regards

Hello,

regarding the server endpoint - that's perfect. Thank you In fact I have not expected it so quickly, please allow for some time - I need to schedule some uninterrupted time to work on this. I will edit your post to remove the precise address - I already have a copy.

Best regards

Regarding the Live Mapping: The UA Complex Data Types can be used with it, but the whole value will look like one UAGenericObject.
There is currently no mapping of UAGenericObject to custom C# types, or Live Mapping "into" the members of UAGenericObject/GenericData. These features are something that we definitely know about and considered, and I am quite happy you are interested in such advanced concepts - but the support for it is not yet available, sorry.

Thank you.

It is now clear that the ArgumentException you got is a QuickOPC bug. We will fix it. Which version are you using?
But, even after the fix, you will still receive the exception - it will be the "proper" (or "better") one: "The OPC UA server has returned a null result, but this operation requires a non-null value.". This exception has to do with various pieces of information about the complex data type we need to obtain from the server - but it is not clear where precisely it fails. Resolving it would be more difficult. Ideally we would like to be able to reproduce it on our side and work on it independently, to save you (and us) from many and many round-trips between you and us and improving the diagnostics etc. It should be said that this combination (methods calls + complex data types) only received limited testing, because few were available for testing.

Is this an embedded server, or PC based? If it is embedded, is there a PC version of it? Can we get access to it (and the configuration) somehow? Or, would it be possible that you expose the server endpoint on the Internet (with firewall open to just our IP address for testing) or over VPN?

Kind regards