Professional OPC
Development Tools


Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

Async Read in OPC UA

02 Mar 2023 08:49 - 02 Mar 2023 08:53 #11588 by support
Replied by support on topic Async Read in OPC UA

The answer to your original is negative - we do not have ability to make asynchronous Read calls. And, it is not planned. In fact, the fact that the QuickOPC API is synchronous (between the library and the developer; not necessarily internally), is among several "foundation" design decisions that are most likely not going to go away. They were made so that the API remains simple - while knowing perfectly that there are use cases where that becomes a limiting factor. Another example of such decision where simplicity wins is the fact that Browse returns all the results at once - even though that may mean very large and long browse (many nodes), which internally uses "continuation points" and could be therefore split to multiple smaller parts, if the API supported it.

Depending on how well your server would handle that, you might be able to overcome our limitation by creating a separate instance of EasyUAClient object for each target PLC, and set the "Isolated" property in all of them to 'true'. This will result in up to 200 separate OPC UA sessions to the server (which may go well, but may also bog down the server or the client - it needs to be tested out). With these separate EasyUAClient instances, you can then keep using synchronous calls, but if you use multiple threads, and one thread makes a Read on the EasyUAClient for one PLC and a second thread makes a Read on a different EasyUAClient for items that reside on the second PLC, they will execute in parallel and therefore even if one blocks, it will not block the other, which is the result you want.

Unless you are actually communicating to so many PLCs at the very same time, the actual number of concurrently opened sessions will be much lower, because QuickOPC closes the sessions that are not in use automatically.

One last note: With either the "full asynchronous" approach (some other library), or the above proposed multi-session approach, you still need to verify that the OPC server is actually capable of handling the requests in parallel, and won't serialize the requests internally. Imagine an async approach where your client will issue "Read Request 1" followed by "Read Request 2". A not-so-good server may simply start executing "Read request 1" AND block "Read Request 2" until it sends you "Read Response 1". In such case the asynchronicity will be there, but it wouldn't help you. The behavior of the server should better be checked before you settle on a way to go.

Best regards
Last edit: 02 Mar 2023 08:53 by support.

Please Log in or Create an account to join the conversation.

28 Feb 2023 14:02 #11580 by denning_s
Replied by denning_s on topic Async Read in OPC UA
Firstly, thanks for the very quick response.

Your assumption is correct, we have just one OPC Client talking with one OPC Server on the same machine. The OPC Server will communicate with potentially 200+ PLCs on various types of industrial network.

In the future, it's feasible that we may want to communicate with embedded OPC Servers on the industrial networks. However, this will be an exception and is not our top priority at present.

Please Log in or Create an account to join the conversation.

28 Feb 2023 13:50 #11579 by support
Replied by support on topic Async Read in OPC UA
a question:

Does your client talk to just one OPC server - and the server then in turn talks to multiple PLCs? (I think this is the case but need to know for sure). Or, does your client talk to multiple PLCs directly, and each PLC has its own embedded UA server?


Please Log in or Create an account to join the conversation.

28 Feb 2023 13:44 #11578 by denning_s
We're currently undergoing a project to upgrade from DA to UA. We'd ideally also like to make a transition from polling (based around the ReadMultiple method) to a subscription based approach.

We've put together a simple client app based on OPC UA subscriptions. Although this functions perfectly, we've hit one major hurdle with this approach. We sometimes need to combine the value from two different tags to determine, for example, the state of a machine. With a subscription approach, we'd have to contend with race conditions and I don't believe there's a full-proof way of synchronising data from the two tags.

This has led us to re-think the strategy and revert back to a polling approach based on UA. The OPC Server and Client will be on the same machine, so this partly negates the additional overhead involved in polling. However, we do face a different problem with this approach. We have to handle scenarios where PLCs may go offline for extended periods of time. As the ReadMultiple method is synchronous, this can cause blocks and delay reads from all other PLCs. Demotion of devices in OPC has been considered as an option, but this doesn't fully resolve the issue.

What we really need is ability to make asynchronous ReadMultiple requests. Is there any way of achieving this?

We've been exploring some alternative SDK's and have found a few competitor products that do offer this functionality. We'd ideally like to stay onboard with OPCLabs as we like the product and support, but without this functionality we've hit a roadblock.

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.059 seconds