Hello.
The QuickOPC behavior you described "should never happen"; if the target server is generally working, even if things go wrong temporarily (and in your case that may not even be the case), QuickOPC should keep reconnecting without your involvement, and start delivering data again. So, unless there is something weird in your code that causes it, it would be a bug in QuickOPC. And, because it is probably a kind of a deadlock in the shared objects (and EasyDAClient objects, by default, reuse the same internal connection objects even from difference instances), the problem will "replicate" itself to any other EasyDAClient instances, which is what you are observing as well.
Unfortunately we cannot fix it without having a reproducible scenario, plus we do would not fix the old 2018.3 version.
Here is what I think your options are:
1. Set the Isolated property of each created EasyDAInstance to 'true', right after creating it. This will make the objects to *not* share the common connection objects. Unfortunately, even if this works, it would basically mean a memory leak, because the unused EasyDAInstances will stay there.
2. Try with recent version of QuickOPC (can be trial version, or we can give you evaluation license free of charge with the 30-minute runtime limit removed, and instead limited to e.g. 30 days of license validity).
3. If simply upgrading to recent QuickOPC does not help: Still with the recent version, add the following after creation of EasyDAClient:
client.InstanceParameters.EnableNativeClient = false;
This will tell QuickOPC to use a different internal implementation which should not have the problem.
If either 2 or 3 resolves the issue, we will give you additional discount on version upgrade, if needed.
Best regards
