Supplementary explanation: The abnormal situation is as follows
1 My client program can connect and subscribe to the opcServer of the remote device, and it can also communicate and collect data normally. A machine has about dozens or hundreds of point tags
2 After running for a period of time (the duration is not fixed), some abnormalities will occur. From the signal log received by subscription, it can be seen that when the abnormality begins, the number of tag signals received by Client.exe subscription suddenly decreases, and there is no signal log afterwards
3 The machine with the abnormality is just one of the many OpcServers subscribed in batches, and the other machines are still working normally

*****My company purchased the latest version. Based on the experience of updating in recent years, I am worried that there may be some details that I may not understand well, which may affect the production of the factory, so I dare not upgrade directly. The current version number is 5.80.255.2, which is temporarily fixed based on actual usage.

****I think if there is a switch that can be turned on to output the log of the control interaction details between the EasyUaClient bottom layer and the remote opcServer, I would like to ask your official staff to read this log, which may be helpful for this type of problem. It is best to monitor and output the log for a specific URL, such as: OpcServer.Url (opc.tcp://xxxx:4840)

Simon.Yu
2025-7-13 15:12
www.vsksoft.com


 

Hello.

1. Retest with the recent version of QuickOPC. Although there was no specific fix to such an issue, there were multiple changes (such as using a newer OPC UA stack/SDK) that can have influence on this. Let me know if you need a temporary license key to cover the recent version, if you do not own the license yet.

2. Please clarify what you mean by: " a certain device cannot receive any subscribed data,". In my understanding the device doe snot subscribe to the data. It is the OPC client that subscribe to the data from the device Did you mean that the OPC client does not receive data from the device?

3. In the case above, are you saying that no notifications arrive for that device? Or are there still some coming, but with AttributeData being null? Each notification has an .Exception member that is filled in in such case. In such case, is there something in the .Exception property?

4. I do not understand this: "EasyUaClient opens abnormal output and global tracking log output, but cannot find the log of the abnormal device,". Please elaborate of what precisely you mean.

5. I do not understand this either: "the client is forced to notify the internal part. After canceling the subscription of the target device IP, the re-subscription can subscribe to the collected signal normally". What is "cancelling the subscription of the target device IP"? - please explain in terms of call to QuickOPC methods. What are you doing there?

6. Depending on the answers to the above question, there may be different suggestion. But from what I know so far, the problem can be either on the client side, and server side. It looks like that we will need a Wireshark capture of the communication between the client and the server (at the time of the problem - to check if there is any communication still - but also before it).

Regards

Dear Support:

The following is the dilemma I encountered. I have no idea or clue for a long time. There is really no other way. I would like to ask for some advice.

Abnormal scenario description:
1 client.exe: windows server2019+ C# .Core7.0 + OpcLabs.EasyOpc.dll, OpcLabs.EasyOpcUA.dll ... ver: 5.80.255.2
2 A client.exe uses EasyUaClient to connect and subscribe to more than 80 different Opc Server devices
3 Abnormality: After working normally for a period of time, such as: a week later, a certain device cannot receive any subscribed data, and there is no task tracking log or disconnection retry log
4 EasyUaClient opens abnormal output and global tracking log output, but cannot find the log of the abnormal device,
5 When the abnormality occurs, the target device can be subscribed to and communicated with normally through third-party tool software (OpcUA)
6 Through the interface function of the software, the client is forced to notify the internal part. After canceling the subscription of the target device IP, the re-subscription can subscribe to the collected signal normally

The following are the relevant preparations I have made
1 The client.exe performs thread monitoring and log output every 20 seconds to understand the number of internal threads, TaskPool.Count, etc., and no abnormality is found
2 Memory usage is low, CPU load is low, no abnormality is observed
3 Other devices subscribe and collect normally

The situation described above has occurred several times in several of my projects. Because it involves the production environment, this abnormality must be resolved. Do you have any good suggestions and ideas to help me solve it?

Looking forward to your attention and reply

Simon.Yu
2025.7.7 15:59
www.vskysoft.com