Hi J.,

If you need to be super-sure, then you can do the extra reads, of course. But in such case you should also prevent the auto-subscriptions, as I described earlier, AND specify a ReadParameters argument with DADataSource.Device to the Read.
But in my view, it is not necessary.

Hi Zbynek,

The app runs as a Windows service so the start-up delay only occurs when the system is rebooted. Not a big problem.
I was wondering if it would be useful to do a synchronous read/write once every 10 minutes or so to make sure the system has not missed any callbacks.
The server is a virtual machine solely dedicated to running this task, so there are no other apps which could suffer. What do you think?

Met vriendelijke groeten, Kind regards,

J.

Hi J.,

The start-up time can probably be improved if the number of “SubscribeMultipleItems” calls is reduced as much as possible (but, verify this by trying it on a simple app, before proceeding further).
I understand that with the design you have, reducing the number of SubscribeMultipleItems calls is a challenge.
If the start-up performance is acceptable the way it is now, leave as it is.

Best regards,

Hi Zbynek,

I am using one SubscribeMultipleItems per read group and WriteMultipleItemValues for the write groups (after checking whether the values have changed).
Because I use dependency injection and therefore have to adhere to the interface definition

I have hidden all the callback details inside the implementation class you find in the attachment.
Each read and write class has a member of type IDepOPC.

Met vriendelijke groeten, Kind regards,

J.

Hi J.,
I am glad to hear this.

How do you set up the subscriptions? Is it SubscribeItem, or SubscribeMultipleItems? And, if it is SubscribeMultipleItems, is it in “groups” (how large) and how many calls to it?

Best regards,

Hi Zbynek,

As you advised, I am now using the subscription model for the reads and a difference check for the writes.
It takes forever to start up (around 4.5 minutes for 41 groups), but after that, the app uses only 300 ms per 3 seconds (when nothing is happening)
Thanks again for the help.

Met vriendelijke groeten, Kind regards,

J.

Hi J.,

In 5.22 the properties exist as well, but they live under different names.
Just have a look (using IntelliSense), or use the doc. I think that for the static parameters it would be something like EasyDAClient.TopicParameters….., and for the instance parameters it would be something like target.UpdateRates…..

But subscriptions will be truly better.

Best regards,

Hi Zbynek,

The code you sent me does not work when using my EasyOPC version 5.22:





even after adding references to all non-UA OPCLabs.EasyXXX dll.
On the website I see that the latest versions of QuickOPC target Studio 2012 and Framework 4.5.
For reasons beyond my control, I have to stick to Studio 2010 and Framework 4.0.
So, I will make the jump to subscription today.

Met vriendelijke groeten, Kind regards,

J.

Hello Zbynek,

Thank you for your quick and clear reply.
I will try the properties first (quickest) and probably move to subscription later
The 100% problem occurs at the startup of a system when a zillion programs and services load and initialize their data. We have seen in the past that Windows messages get lost in the turmoil, causing some of our apps to hang or behave inconsistently.

Met vriendelijke groeten, Kind regards,

J.

Hi J.

There can be multiple reasons to this, but this one is quite likely:
When you call Read, QuickOPC sets up an OPC subscription internally anyway. This is in attempt to have the values “ready” for you next time, without having to go the OPC server. QuickOPC observes the pattern of Reads, and from time to time, it adjusts the update rate of the OPC subscription. This is done by removing the items from one OPC group and adding them to a different group, which may be time consuming and be the reason of the occasional longer processing times. Writes would be affected indirectly – because (unless you specifically specify differently), only one “channel” is used to communicate with the OPC server, so while the items are being moved, other operations have to wait as well.

Other comments:
- If you commonly get 100% CPU, then you already have a problem, and that one should be solved first.
- You should really use subscriptions for this. Coding-wise, it is NOT much more complicated. It will be better in performance, and it should behave better, not worse, in high-CPU load situations. And the above described mechanism won’t apply.

If you decide to do stay with repeated Reads: We do not provide a straightforward way to disable the auto-subscription and rate-adjusting mechanism described above. But you can try to set the parameters as below – the first two are static properties and should be set just once, at the beginning of the program; the other two are instance properties and should be set on each instance of EasyDAClient (if you have more than one):

When doing it like this, it may very well happen that you Read times will be quite stable, but at the same time, they will be slower than what you observe now – because they will become a “true” OPC reads.

Best regards,