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.


EasyDAClient connections and subscriptions

08 Nov 2022 14:38 #11193 by support

thanks for the information, this is what I needed. If the client restart does not help, and even other clients exhibit the same problem, it is clear that the problem is really on the server side. Of course the proper way would be to fix the server. But if it is not possible, you might be right that it is worth trying to reduce the number of repeated connections/disconnections, and analogously, operations like adding/removing items to/from OPC groups.

QuickOPC handles of all of this automatically, getting rid of "unneeded" connections/objects after some period, if they are unused (no longer asked for).

One way to prevent it is to increase the so-called "hold" periods, but their default values are in range of seconds, maximum tens of seconds. So, if you are reading every 3 minutes, increase the hold periods to e.g. 5 minutes. Here is an example (taken from the product/doc) to illustrate the syntax (although what it does is exactly the opposite - it causes *faster* disconnection) - but that is just a question of the actual value.

// This example shows how the OPC server can quickly be disconnected after writing a value into one of its OPC items.
using System;
using OpcLabs.EasyOpc.DataAccess;
using OpcLabs.EasyOpc.OperationModel;
namespace DocExamples.DataAccess._EasyDAClientHoldPeriods
    class TopicWrite
        public static void Main1()
            // Instantiate the client object.
            var client = new EasyDAClient();
            client.InstanceParameters.HoldPeriods.TopicWrite = 100; // in milliseconds
                client.WriteItemValue("", "OPCLabs.KitServer.2", "Simulation.Register_I4", 12345);
            catch (OpcException opcException)
                Console.WriteLine("*** Failure: {0}", opcException.GetBaseException().Message);

There is not just "TopicWrite", there is also "TopicRead", so you will be changing them too. See's...ClientHoldPeriods_members.html .

I hope this helps.

Also see:

Best regards

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

08 Nov 2022 06:07 #11191 by mlebelle
Tanks for your reply. Starting the client does not help. We also used the Matrikon OPC client and this one shows the same problems. The only way to solve the problem is by starting the server. We have3 applications running and I suspect that the ABB OPC server cannot deal with opening/closing the OPC connection and/or subscribe/unsubscribe to OPC items and destroy/re-create an OPC groups many times. We just try to find a solution so that the ABB OPC server does not fail/crash.

1. The first application reads about 700 items from the OPC server every 6 minutes and writes 1 item
2. The second application also reads some items but not more than 100 very 2 minutes. It also writes some items based on events. The number of items written is about 3
3. The third application is reading some items every 3 minutes. Maximum 200.

If need be I can give you the exact numbers per application.

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

07 Nov 2022 10:46 #11189 by support

I will answer all your questions, but first let me ask myself:

You wrote "The only way to solve the problem is by rebooting the ABB OPC server. ". Can you confirm that, when the problem happens, shutting down your QuickOPC/VB6 application, and starting it over again, does *not* help?

I am asking because if restarting the client side helped, there would be a possibility that there is a real problem (bug) on the client side (QuickOPC). If, however, restarting the client side does not help, it would imply that the server side is really at fault (the tunneller or the target server), in which case we may discuss if there is some workaround - but the distinction between the two cases is very important.

Thank you

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

07 Nov 2022 10:04 #11188 by mlebelle
We are using Quickopc in a VB6 environment and use the following to functions:
- client.ReadMultipleItems(arguments)
- client.WriteMultipleItemValues(arguments)

We use a Softing OPC tunneller but I think that is not causing the problem.

The communication works well at start up but after 1 or 2 days the ABB OPC does not respond anymore to any OPC call. We have no idea. The only way to solve the problem is by rebooting the ABB OPC server. The following error appears:
vtgResult returned not succeeded status. tag: OPCTunnel.ABB_OPCServer.29LI-038:OUT VAlue Status = NOTSUCCESS System.TimeoutException: Cannot connect topic (timeout). The client method called (or event/callback invoked) was 'ReadMultipleItems[672]'.

I have some questions about the internal functionality of the quickOPC functions.

1. I defined outside the client object outside the function that is reading or writing the OPC data
Option Explicit
Dim client As New EasyDAClient
Public Function OPC_GetList(OPCServer As Variant, OPCTagList() As Variant, OPCAtomList() As Variant, OPCIdx As Variant, AAGValueList() As Variant, AAGStatusList() As Variant) As Variant

2. How does the object deal with opening and closing connections? Does it keep the connection open all the time or does it open and close for every read/write call?
3. How does the object deal with item subscriptions and OPC groups? Does is re-create the OPC group and item subscription for every read/write call or does it only create the OPC group and the items in the group at start-up (the first call).
4. Is there a way to change the standard behavior?
5. Do you have any other advise to solve this problem?

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

02 Jul 2022 17:55 #11027 by support

The API (methods) for reads/writes on the EasyDAClient are synchronous. Internally, QuickOPC selects *some* method to perform the operations, depending on which interfaces the OPC server provides. By default, asynchronous OPC calls are preferred.

The answer to your questions depends on what actually is meant by the word "fully" in "This ABB OPC server does not fully support asynchronous (subscriptions) OPC operations.".

If the interfaces for asynchronous reads/writes are not supported by the server at all, QuickOPC will select the synchronous interfaces, and the read/write methods you listed will work fine. Only if the OPC server has somehow "incomplete", non-functional implementation of the async interfaces, it would be necessary to do more. QuickOPC has settings to enforce the synchronous operations, which I can help you with. But there is no reason to do that unless you are having problems. Have you tried the methods you listed, and what were the results?

Best regards
The following user(s) said Thank You: mlebelle

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

30 Jun 2022 05:02 #11020 by mlebelle
We are using the easydaclient in a Visual Basic 6 development environment. We need to communicate with an ABB OPC server. This ABB OPC server does not fully support asynchronous (subscriptions) OPC operations. So we want to make sure that we use synchronous OPC operations only. We are using the following functions of the easydaClient. Are these functions asynchronous or synchronous operations and how can we force them to be synchronous or do we need to use other functions?


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

Moderators: support
Time to create page: 0.061 seconds