Professional OPC
Development Tools

logos

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.

Occasional exception when writing to tag

More
07 Jun 2017 11:00 #5200 by support
What you have described is not, in essence, different from the tests we have already made.
Please send the whole program, and the server configuration, if you can.

Best regards

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

More
05 Jun 2017 09:25 #5191 by sebpinski
Below I've pasted all of the settings I use. This issue occurs after repeatedly doing single/multiple reads and single writes to a set of tags that are reporting bad data. The only way I can describe a way to reproduce is to setup two new channels/devices in an OPC server (we mainly use the modbus driver), one with a connected device, the other with an unreachable IP address (so that all tags are returning bad data). Setup a loop to continually read/write from both devices. At some point you'll find that all reads and write return the "Cannot connect topic (timeout)." Where good data isn't read, but even if you suddenly connected a device on the channel that was setup to be bad, it still would not recover.
            EasyDAClient.SharedParameters.Topic.SlowdownWeight = 0.0f;
            EasyDAClient.SharedParameters.Topic.SpeedupWeight = 0.0f;
 
            _opcClient = new EasyDAClient() { Isolated = true };
 
            _opcClient.InstanceParameters.Mode.DesiredMethod = OpcLabs.EasyOpc.DataAccess.Engine.DAReadWriteMethod.Asynchronous;
            _opcClient.InstanceParameters.Mode.AllowAsynchronousMethod = true;
            _opcClient.InstanceParameters.Mode.AllowSynchronousMethod = false;
 
            _opcClient.InstanceParameters.Timeouts.ReadItem = 10000;
            _opcClient.InstanceParameters.Timeouts.WriteItem = 10000;
 
            _opcClient.InstanceParameters.UpdateRates.ReadAutomatic = Timeout.Infinite;
            _opcClient.InstanceParameters.UpdateRates.WriteAutomatic = Timeout.Infinite;

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

More
04 Jun 2017 07:15 #5190 by support
If this is a bug in QuickOPC, we just need one thing - a reproducible scenario that would allow us to see and investigate the problem on our computers. So far, unfortunately, we could not reproduce it.

The only thinkable workaround is to restart the process. Other kinds of "workarounds"(such as creating new EasyDAClient objects with Isolated = true), if they work at all, would only turn the problem into a resource leak, because the old (blocked) stuff will internally still live and occupy memory, threads, handles, etc. - and this consumption will grow over the time.

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

More
02 Jun 2017 09:27 #5189 by sebpinski
Apologies for re-opening a three year old thread, but has any work been done to investigate this issue?

We've been seeing the exact same sequence of events. If a read fails for whatever reason, we get this kind of domino effect where no subsequent reads are successful. Even though a restart fixes the issue.

I know that in other threads I've been told that the EasyDAClient does not ever need to be 'refreshed', but there are too many issues where subscriptions die, reads fail, with no actual way to recover the situation without a brute force approach. Is there no method that can be added to refresh the EasyDAClient?

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

More
06 Dec 2014 08:52 #2544 by support
Yes, the first error (read not completed, or write not completed) essentially means that something has blocked for either too long or forever during the actual read or write, while the second error (cannot connect topic) indicates the same kind of problem, but a bit earlier in the process (when trying to add an OPC item to the OPC group, which has to be done before the actual read or write). The fact that these two errors appear in this sequence indicates that something has blocked, either inside the server or in the client - which negatively impacts the subsequent operations of course.

I would also suggest to do this: www.opclabs.com/forum/reading-writing-subscriptions-property...tions-made-with-opc-reads#1761 .

Best regards

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

More
04 Dec 2014 23:16 #2537 by cromarty
Perhaps it's little bit too early but I think I found a solution. Additional logging revealed that one or two tags failed to send with this error: "Write not completed. This error indicates that it could not be verified that the requested write operation was completed during the timeout period. It is possible that the write operation will actually succeed or fail, but later. Increase the timeout period if you want to obtain positive or negative indication of the operation outcome. Other reason for this error may be that under heavy loads, topic request or response queue is overflowing. Check the event log for queue overflow errors (if event logging is supported by the product and enabled)."

On the next scan all 32 tags would fail with this error: "Cannot connect topic (timeout)."

I suspect that the former error would cause the latter so I looked for possible solutions to the first error. Another post on this forum suggested to change synchronous and asynchronous settings of EasyDAClient. I have done that and found that when AllowAsynchronousMethod = false and AllowSynchronousMethod = true plus DesiredMethod = DAReadWriteMethod.Synchronous then I no longer get errors.

I've only just tested it overnight (around 20 hrs) but normally I get would plenty of errors during this time. Instead I got none.

My current setup for EasyDAClient:

opcClient = new EasyDAClient();
opcClient.ClientMode.Isolated = true;
opcClient.ClientMode.AllowAsynchronousMethod = false;
opcClient.ClientMode.AllowSynchronousMethod = true;
opcClient.ClientMode.DesiredMethod = DAReadWriteMethod.Synchronous;
opcClient.Timeouts.WriteItem = 60 * 1000;
opcClient.HoldPeriods.TopicWrite = 240 * 1000;

Some of these settings are from earlier suggestions but I kept them as they don't appear to do any harm.

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

More
14 Oct 2014 21:12 #2434 by cromarty
Yes the problem is still occurring. Additional logging will hopefully show me how often this happens and if I can recover from it by reconnecting. I have moved the heartbeat signal to be sent along with other data using WriteMultipleItemValues, rather than on its own.

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

More
14 Oct 2014 09:14 - 14 Oct 2014 09:14 #2431 by support
I did not get from your reply whether the problem has occurred after making the recommended changes - can you please state the result.

The WriteItemValue is really just a thing wrapper for WriteMultipleItemValues. If using WriteMultipleItemsValues - with a single item - seems to help, I think it is just a coincidence. The WriteItemValue code look similar to this (implemented as extension method; contract checking statements removed for simplicity):
static public void WriteItemValue(
    [NotNull] this IEasyDAClient easyDAClient,
    [NotNull] ServerDescriptor serverDescriptor,
    [NotNull] DAItemDescriptor itemDescriptor,
    [CanBeNull] object value)
{
    var argsArray = new[] { new DAItemValueArguments(serverDescriptor, itemDescriptor, value) };
    OperationResult[] resultArray = easyDAClient.WriteMultipleItemValues(argsArray);
    OperationResult operationResult = resultArray[0];
    EasyUtilities.CheckSuccess(operationResult);
}

where the EasyUtilities.CheckSuccess just throws an exception if operationResult.Exception is not null.
Last edit: 14 Oct 2014 09:14 by support.

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

More
14 Oct 2014 00:15 #2430 by cromarty
The problem is intermittent, so I'm struggling to reproduce it. However I have added Isolated = true and set HoldPeriods.TopicWrite to 120 seconds. I'm only using one EasyDAClient for my whole application.

For now I've added extra logging and I'm detecting when this exception occurs and disconnect. After 5 minutes I'll try to reconnect to see if the connection is okay.

I have noticed that this exception happens when I use WriteItemValue for heartbeat but I don't get any exceptions when I send other data using WriteMultipleItemValues (at the same 1 second interval). Perhaps one workaround may be to remove the call to WriteItemValue and incorporate hearbeat into WriteMultipleItemValues.

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

More
14 Sep 2014 07:04 #2285 by support
This may be a problem in QuickOPC, unfortunately without having a reproducible case we cannot get to its true cause.

If you are also doing "one-shot" reads somewhere, I recommend making parameters changes described here: www.opclabs.com/forum/reading-writing-subscriptions-property...scriptions-made-with-opc-reads .

I also recommend setting the property Isolated = true on the EasyDAClient instance you use for the heartbeat, and, in fact, on other instances of EasyDAClient as well, as long as you do not mind a slight increase in client and server resource consumption it can cause.

In your particular case, it is weird that you get "Cannot connect topic (timeout)", because with writing to the same item each second, it should stay "connected" (= in the OPC group object on the server) all the time (the default "hold period", after which we keep the item in the OPC group, is 30 seconds, i.e. much longer. Have you monitored the moments the write is actually performed, to see if there isn't any unexpected long pause (I mean, *before* this problem occurs), caused e.g. by some other CPU-intensive work in the process, or the way the timing (periodic execution) is implemented?

Hold periods can be modified (prolonged) in the InstanceParameters.HoldPeriods object (on each instance of EasyDAClient separately).

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

Moderators: support
Time to create page: 0.076 seconds