Hi,

Very much thanks for posting this.

The reason why this happens has nothing to do with a Method call, but this also fails as a consequence. The actual underlying problem is actually somewhat nasty interop problem sort of. The NodeSet XML for the standard model incorrectly defines the AccessRestrictionType as a subtype of UInt32, when it should be of UInt16, that is used in the specification text. Thanks to your post we are now aware of this.

Our SDKs functionality derives directly from the NodeSet’s data is certain areas, thus our SDK is expecting an UInt32 value, and it will fail to read the node object properly if it receives anything else. This is assuming the node actually defines a proper value for the Attribute. It was added in OPC UA 1.04, our server side (and not many others as well) support that yet, thus no error (and if we are communicating with ourself SDK-wise, it would have been the incorrect UInt32 in our impl anyway).

The Foundation sample seems to be a server (the first that I have seen, though in general no wonder as they do test the stuff they specify) that gives a value, thus us failing to read the nodes, which define the parameters needed to make the method call.

Seems the Foundation is aware of this (for few days): https://apps.opcfoundation.org/mantis/view.php?id=6025 (requires credentials). So preferably this will be fixed once the NodeSet is updated. Before that we can try to make a workaround (at least reading-wise, due to the deriving from the NodeSet writing would be an issue, unless we decide to modify the nodeset ourself, but that might have other issues and complexities depending on how many places the type is used).

It should be noted that the incorrect subtype definition is probably seen in every server DataType-hierarchy, but it then depends if the server is actually using that to derive the functionality. In this case, the sample does send the data properly as UInt16 on the wire/binary.

We do now have a beta version of the Browser, which workarounds the issue, send mail to uabrowser-support@prosysopc.com to obtain if needed.

The workarounds also exists now in our latest SDK (beta) build (that is what the app uses). Though, it should be noted, that for the time being the workround does convert UInt16 values to UInt32. This is technically incorrect, as the UInt16 is the proper type, but until it is fixed by the OPC Foundation on the nodeset level, it had to go that way (we’ll flip the conversion logic once that happens; now if UInt32 is received it will log on WARN level, but we’ll use it as-is for the time being).