Questions about OPC UA Client Read

[AppleCitron]

Hello, I have a question regarding OPC UA Read.

The terminology varies slightly between servers and clients, so I wanted to confirm if my understanding is correct.

In KepServer Quick Client, there are two types of Read operations: Cache Read and Device Read.

Additionally, in Eclipse Milo, there are two examples related to Read: ReadExample and ReadNodeExample.

ReadNodeExample utilizes the AddressSpace for Read functionality, while ReadExample involves calling the Read operation, where the MaxAge parameter can be configured during the Read call.
Is it correct that the Cache Read functionality mentioned in KepServer or other OPC servers/clients corresponds to setting a higher MaxAge value when calling Read in Milo?
Similarly, does the Device Read functionality mentioned in KepServer or other OPC servers/clients correspond to setting MaxAge to 0.0 when calling Read in Milo?
In Milo, Read requests are handled asynchronously by default using .get(). How can I perform a synchronous Read operation?
If it’s challenging to match Cache/Device Read with Milo’s functionality, could you provide a brief explanation of the Read functionality provided by Milo?

[kevinherron]

I don’t know for certain how these Kepware options map to OPC UA. I assume it would be the max age parameter for a “cached” read.

Sync vs async is something from OPC Classic (COM) I believe. There is no distinction in OPC UA. Milo let’s you do either style by either blocking for the future result or using a callback on the CompleteableFuture.

Also be aware Kepware Quick Client does not use OPC UA to connect to itself - it uses OPC Classic.

[AppleCitron]

Thank you for your response.
I don't quite understand the difference between synchronous and asynchronous methods. To me, it seems like it's only asynchronous.
Could you explain how synchronous reading works in the Milo Client or show me an example code for requesting a read?

[kevinherron]

Calling .get() on the CompleteableFuture makes it synchronous. It’s from the point of view of the caller / user of the API.