There were no significant changes to the logging/tracing.
We will go that route if you keep having issues.

Best regards
 

Hi ,support:

    What changes have been made to the output of the log layer in the recent update? Can more details be traced through log control?

I have updated and referenced the latest package source from Nuget, compiled and released it to the customer; 

EasyUAClientOnLogEntry-Trace.log :

$Collector' -> Name: "BaseLib", Version: "5.84.192.1".
Time' -> UtcNow: 05/12/2026 03:33:35, Now: 05/12/2026 11:33:35, TickCount: 592744265.
AssemblyAttributes' -> AssemblyConfiguration: "Release".
ExecutingAssembly' -> FullName: "OpcLabs.BaseLibPrimitives, Version=5.84.192.1, Culture=
AppDomain' -> FriendlyName: "DataCollect.Client", Id: 1.
SystemAssembly' -> FullName: "System.Private.CoreLib, Version=8.0.0.0, Culture=neutral, 
Clr' -> ClrVersion: "8.0.26", PtrSize: 8.

Simon.Yu
2026.5.12 
 

Hello.

We have just released QuickOPC 2026.1. And, it has a relevant change in the reconnection algorithm, related to the issue you reported.
So, the plan is as follows:

1. Rebuild your projects with QuickOPC 2026.1.
2. Retest.
3. If the issue persists, we will proceed as indicated earlier, i.e. giving you individualized instructions/software builds for better diagnostics (tracing etc.).

Best regards
 

Hi,Support :
  Can there be any progress recently?

Look forward to your reply

Simon.Yu
2026.5.6

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