- Posts: 4
- Thank you received: 0
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.
Groups
thank you for fixing it. With the new library the read-times are 3 to 10 times faster and only one group gets created.

Best regards
Please Log in or Create an account to join the conversation.
I was able to reproduce the problem. It depended on the server, that's why I could not reproduce it earlier. Thank you for reporting it.
We have fixed the issue. Please download and install the current version available, and rebuild your project with it. The version/build number should be 5.53.405.1 or higher.
Best regards
Please Log in or Create an account to join the conversation.
these settings did have no effect on the number of created groups.
The OPC Factory Server still shows 77 Groups for 77 Active Items, both on ReadMultipleItems (second example) and on subscribing and waiting for changes (SubscribeMultipleItems, first example).
The only difference between read and subscribe and wait for changes was the number of active groups. On reads it was 0 - but it still created 77 groups - and on subscribe and wait for changes it was 77 active groups.
Best regards
Please Log in or Create an account to join the conversation.
If you do Reads, QuickOPC creates groups for them as well, and then dynamically changes their parameters (or deleted/creates new ones) based on the frequency of the reads - or the anticipation thereof. This may be the cause.
Best regards
Please Log in or Create an account to join the conversation.
I can reproduce this every time. The Code for subscribed reads is:
The code for "grouped" reads is:
Please Log in or Create an account to join the conversation.
Please post here the source code you are using (in its minimal form needed to reproduce the issue).
Also post here the relevant screenshot showing form your test run, showing the number of groups. I want to be sure that you are not misinterpreting it.
Best regards
Please Log in or Create an account to join the conversation.
We will try to reproduce this. For subscriptions with the same parameters, only one group should be created, I agree. If it is not happening, it would be a bug and we will fix it.
Best regards
Please Log in or Create an account to join the conversation.
we tried to reduce the number of created groups for tag subscription by following the example in the Forum entry 'Group name, deadband' by using SubscribeMultipleItems, but the EasyDAClient still creates one group per tag, so if I subscribe 170 tags at once I get 170 groups (visible in the status-window of the OPC-Server).
I made a quick test by modifying the example _EasyDAClient.ReadMultipleItems.TimeMeasurements from the QuickOpcCSharpExamples to read 170 tags with ReadMultipleItems from our OPC-Server to exclude, that our component does some settings which may influence this, but even with this I get one group per tag.
In the documentation of the OPC Factory Server (OFS) is written, that one should limit the number of groups for performance-reasons.
We are experiencing serious performance problems in another OPC-Server (the one integrated in Schneider Electric’s Vijeo Citect System), which is the reason, why we are now in the process of setting up a dedicated OPC-Server. The Citect-OPC-Server does not show the number of used groups, the OFS does this.
The Library used is QuickOpc-2016.2-Full, the version of the tested OPC Factory Servers are 3.60.3108.0 and 3.60.3112.0.
Is there another option which can be set in the EasyDAClient to tell it, that it should only use one group with all items when using ReadMultipleItems or SubscribeMultipleItems?
Thanks
Please Log in or Create an account to join the conversation.