OK, we will proceed as I have described, i.e. by enhancing the tracing inside QuickOPC. However, be prepared that it will not be ready soon. The preliminary plan is to implement these changes into the release of version 2026.1, for which we are targeting April 2026, or is a subsequent revision.

Regarding the changes you are making, be aware of the following: If your code currently uses EasyUAClient in such a way that each instance is only used to perform operations on one server (endpoint), then setting Isolated = true has, by itself, no effect whatsoever. Setting Isolated = true only has effect on how different EasyUAClient instances access the same endpoint.Regards

At present, the program has been updated and an isolation mechanism has been adopted, with Isolated=true enabled. At the same time, each IP corresponds to a dedicated EasyUaClient instance to check and determine specific high-frequency disconnection anomalies. A timer checks all IP disconnection situations every 5 minutes. If a high-frequency disconnection is found, the EasyUaClient corresponding to the target IP cancels the subscription, releases the object, and then re creates the isolated object and re subscribes;
At present, it seems that there are signs of something taking effect. I will keep updating the progress of these situations until this point, hoping to completely resolve them

Simon.Yu
vskysoft.com
2026.3.11 09:29

Hello
Thank you for your continuous attention and responses. In my recent two replies, I have indirectly addressed and responded to the points you previously cared about.
I truly cannot provide the information you seek directly, as this situation is not common—sometimes it occurs frequently, while other times it may happen once every few months.
Moreover, this disconnection issue does not occur every time, making it somewhat challenging to address, primarily due to its passive nature.
The client program is a subscriber and cannot arbitrarily control device switches or conduct targeted testing.

Simon.Yu
vskysoft.com

Hello. You have not answered any of the three questions I asked you.However, it appears from your two new posts that you cannot reliably reproduce the problem no matter what. In such case, I can only propose following approach:

1. Knowing which areas are "suspected", we will add additional instrumentation (tracing) to the code, and give you new QuickOPC version and instructions how to enable the tracing.
2. You will run this in production environment and wait until the issue occurs.
3. You will send us the collected information.
4. We will evaluate it.
5. If the information shows enough information about the issue, we will work on resolving it. Otherwise, we will enhance the instrumentation even further, and the process will loop to Step 2 above.

 Regards
 

Temporary testing plan prepared:
1) Priority: Isolated=true, create an EasyUaClient for each IP, and if an exception is detected, log out and rebuild the client directly
2) Next: Assembly Space Isolation
3) Finally, a proxy is responsible for automatically scheduling and creating multiple processes at the bottom layer, with each IP having an independent process. It checks for exceptions internally, automatically logs out, and rebuilds EasyUaClient
So these are the few solutions that I least want to face, which obviously add too many manual and unreasonable designs, and seem like a rather foolish approach
4051 exception does not occur every day or every month, but once it occurs, it can only be resolved by restarting the client (EasyUaClient), which seriously affects the industrial production environment

Simon.Yu
vskysoft.com

I am glad to receive this long-awaited response. Thank you for your attention and reply

At present, the main log documents for viewing IP disconnection and connection are OPC_Srv-ConditionChanged.log and EasyUAClientOnLogEntry-Trace.log. The code is decompiled with AI analysis assistance

OPC_Srv_ConditionChanged.log 
....
2026-03-02 16:53:50.232 Disconnecting ,opc.tcp://10.10.100.114:4840
2026-03-02 16:53:50.237 Disconnected ,opc.tcp://10.10.100.114:4840
2026-03-02 16:53:51.471 Disconnected ,opc.tcp://10.10.100.114:4840
2026-03-02 16:53:55.494 Disconnected ,opc.tcp://10.10.100.114:4840
....
2026-03-02 23:59:07.996 Disconnected ,opc.tcp://10.10.100.114:4840
2026-03-02 23:59:08.038 Disconnected ,opc.tcp://10.10.100.114:4840
...
2026-03-02 23:59:11.478 Disconnected ,opc.tcp://10.10.100.114:4840
2026-03-02 23:59:11.527 Disconnected ,opc.tcp://10.10.100.114:4840

Why does the internal end result in infinite and continuous high-frequency disconnections? This should be a bug, and it should not be like this no matter what; 

I have carefully observed that in my own projects, there are usually 5-10 client.exe  that communicate with over several hundred OPCS servers. Every day, there are several or more devices that are disconnected or restored to online, but can still reconnect. The probability of 4051 occurring is very rare, but after a 4051 error code appears, there is a high probability that it will not reconnect and there is no reconnection log. In reality, the machine is always online

Other aspects related to maintaining conversations holdperiod、 I have tried reconnecting the interval and other methods, but have been unable to solve it. This problem has been going on for almost 2 years, and currently I cannot think of any solution

If an active monitoring is added and it is found that the high-frequency and continuous disconnections mentioned above, Can I solve this problem by setting all tags in the target IP to unsubscribe and subscribe?

I really can't think of any other way

Simon.Yu

vskysoft.com
2026.3.6 15:30

Hello.I agree that if it is actually possible to connect to the server (I am not sure about it - we would need a Wireshark trace), that

• QuickOPC should eventually make the reconnection, and
• The repeated Disconnected notifications are not by design (although by itself, I consider it a small bug)

The AI analysis is full of errors and makes little sense when compared with what the code actually does. It looks like that the AI misunderstood the purpose of the various timers involved. There might be *some* useful info in it, but it is hard to tell. The recommended AI solutions are mostly rubbish, they are either unapplicable or would introduce other bugs.

I need to reproduce the problem here in order to be able to make progress. Using the problem statement you gave to the AI, I made a setup consisting of a client program, and one local server, and one remote server. The code is attached. When I run the program, I disconnect the network cable from my computer to the network (= to the remote server), and I reconnect it back after some time. I got the expected behavior, i.e. QuickOPC reconnected to the remote server. 

Network cable was unplugged on 11:17:00
Network cable was plugged back in on 11:23:00
The output from the program is attached.

If you want this to go forward, you need to provide me with reproducible scenario. Questions:

1. Did I understand the scenario correctly, i.e. would *you* think that the provided program should manifest the problem, or not?
2. If I have understood it correctly, and you run the same program (you can change the server endpoints and node IDs to something else.), does it show the problem you reported?
3. If I have not understood it correctly, modify the program so that it shows the problem when you run it with your servers. Send me the modified program, and I will check if I can reproduce it here with my servers.

 

Hello.

We will review the information you provided. It will take some time. Will post here when we have an update.

Regards
 

 

Dear technical support:
I spent a lot of time talking to tokens and AI in order to understand whether the current problem can be located and solved, and also to enable QuickOPC officials to quickly understand the importance of this issue to my work. I am extremely eager to solve this problem and provide you with detailed AI analysis documents and solutions (AI provided ideas);

Problem description:
1) The infinite, high-frequency, and continuous disconnection after disconnection is unreasonable from the perspective of communication explanation. There must be a connection and then disconnection
2) The machine is manually powered off, disconnected from the network, or shut down. After 5 minutes, it can be restarted and restored to normal status, but cannot be successfully reconnected
Expectation: Could you please take a few minutes to review the document I provided (AI scanning conclusion and repair suggestions)