Flow control for remote device reads

[leesmith1985]

Hi,

I am creating an OPC UA server which connects to a remote device via proprietary RS232 serial communications. Communications with the device are sometimes slow and so I need to use an asynchronous read model. As previously advised, to deal with this asynchronous read scenario, I return null on the following read method:

Code: Select all

protected override DataValue Read(RequestContext context, NodeAttributeHandle nodeHandle, string indexRange, QualifiedName dataEncoding)

I then use the following method to instigate read requests on a seperate thread and return using the callback when the operation completes:

Code: Select all

protected override void Read(RequestContext context, TransactionHandle transaction, IList<NodeAttributeOperationHandle> operationHandles, IList<ReadValueId> settings)

So first question, whats the difference between the two above read calls? Under what scenario are each called?

Secondly, obviously there will quickly come a point where the serial communication bandwidth to the device is fully consumed. In this case, is there any way I can indicate to the SDK that I'm no longer able to read at the specified interval? Obviously, if the client creates a monitored item subscription to a few nodes and samples very frequently, this scenario can happen almost immediately. I end up with lots of Read calls which the device simply can't keep up with. So how can I deal with this? Am I obliged to invoke the callback for every read transaction handle?

Thanks, Lee

[Support Team]

The first Read method shall return data which can be returned immediatelly, especially in-memory data. If there might be any delays in returning the data, null has to be returned.
The implementation of the BaseNodeManager will return all values for all non-Value attributes and the values for Value attribute for Internal and InternalPolled nodes. If the nodes are configured as ExternalPulled or ExternalPushed, null will be returned.

The second Read method is called by the SDK for all attributes where the first Read method returned null. You have to get the value and call the callback of the NodeAttributeOperationHandle. This allows you to get the value in a worker thread and call the callback in this thread. So the server will not block.

If the communication to the underlying device is problem when having many MonitoredItems or having MonitoredItems with very small SamplingIntervals, you should Cconfigure the Variables as ExternalPushed and do your own sampling.

We will add a detailed example in SDK 2.5.4.