Oh, I see.
So you have effectively already done what I have suggested, just the concrete timing parameters are somewhat different.

This is an interesting case. In principle both parties (the client, and the server) are doing what they should. The limitations on the server are natural and cannot be fully avoided. And the client has no way of knowing that it should not attempt to connect with certain rate.  For this reason I am hesitant to call it a bug in the client either.

We strive to build all reconnection logic into QuickOPC, so that the developer does not have to do extra coding - like you now did. So perhaps we can, as future improvement, attempt to recognize this particular problem, and internally suppress the connection attempts for a while, to give the server a room for breathing. So the code would be inside QuickOPC - and there can be some default delay - but it would still be possible that the developer will have to adjust the delay.

Best regards

The normal execution of the task is to read those tags each second (and it's ok). My workaround is to wait 10 seconds if I get a null value and using those 10 seconds solves the issue (when I have a good value, the task keeps reading data each second). If when I have a null value, I wait 5 seconds, I keep getting null values. It seems like 10 seconds is the minimum wait time to restore the communication beetween me and PLC. 

The workaround can be implemented without any problem.

Hello,
thank you. At least this is gives us some more information.

Before we go the more painful way (with getting and analyzing communication logs), there is one more possible explanation. It could be that the PLC reboot and the fact that the application keeps attempting to open new connection, do not play well together. The PLC probably has limited number of incoming connections, and if the rate of cleaning them up in the PLC is slower than the rate of new attempts, the situation would not resolve itself.

For test, can you add an extra code to your application that, in case of *this particular error*, will pause your Reads for some time? (I suggest 1 minute, but since slowing down the Reads to 10 seconds actually helped, then a delay even shorter than 1 minute would do - but let's start with the very safe choice).

Best regards
 

Hello,

I tried with this code:
     easyUAclient = new EasyUAClient();
     easyUAclient.Isolated = true;
     easyUAclient.IsolatedParameters.SessionParameters.HoldPeriod = 1000;
And I put 5 seconds from one Read to another. 
The issue is not solved and the problem is the same, I keep getting null values if a server disconnects and then reconnects.

Hello,
thank you.

It's good that you found this workaround, because it also tells me a bit more - although still not enough - about where the problem might be. It appears to be related to automatic session opening/closing.

If you want to keep your 5-seconds reading interval, can you please try a different workaround: Set the session HoldPeriod property to much smaller value (500 or 1000) - opclabs.doc-that.com/files/onlinedocs/QuickOpc/2022.1/User's...sionParameters~HoldPeriod.html .

Regards

Hi,

Version is: 5.63.246.1

 

Hello.

Which QuickOPC version are you using please?

Regards

The inner exception the system is giving back is: "No connection could be made because the target machine actively refused it".
It happens with 2 different PLC brands (Siemens and Beckhoff). 
Also, I found that increasing the delay beetween 2 "Read" to 10 seconds, the problem disappears.

Hello.

You are right that the expected behavior is that QuickOPC should reconnect, without extra effort on your coding side. So we need to investigate that.

First thing I need to know is, when you receive the null value, whether the .Exception in the UAAttributeData is also null, or - when it is not null - what are the exception details.

Best regards

Hello,

I'm facing a problem with OpcLabs 5.63.
In my windows service I'm reading a PLC tag every 5 seconds with this instruction: "UAAttributeData attributeData = easyUAclient.Read(opcServerName, itemName, UAReadParameters.FromDevice);" where easyUAclient is an instance of EasyUAClient class.
I found that after a PLC reboot the Read method is always returning null value. If I restart the windows service, everything is going to work fine, but of course I cannot restart the service every time the PLC is reeboted.
Is it there any way to restore the connection or something like that? 

Thank you!