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.

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?

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.

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.

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.