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.
- Forum
- Discussions
- QuickOPC-Classic in COM
- Reading, Writing, Subscriptions, Property Access
- EasyDAClient connections and subscriptions
EasyDAClient connections and subscriptions
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
try
{
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 opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User's...ClientHoldPeriods_members.html .
I hope this helps.
Also see:
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User's...kOPC/Setting%20Parameters.html
Best regards
Please Log in or Create an account to join the conversation.
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.
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.
- 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.
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
Please Log in or Create an account to join the conversation.
client.ReadMultipleItems(arguments)
client.WriteMultipleItemValues(arguments)
client.WriteItemValue
Please Log in or Create an account to join the conversation.
- Forum
- Discussions
- QuickOPC-Classic in COM
- Reading, Writing, Subscriptions, Property Access
- EasyDAClient connections and subscriptions