Frequent 'Read Failed' messages, unable to maintain connection for long period

[astroman]

I've been working on a number of AdvancedHMI projects for the past two months, but I have been unable to circumvent the 'Read Failed - Result=-20' message. I use SLC and CLX drivers and I mainly run version 3.97d. I use roughly 30 DataSubsribers per project and perhaps 30-50 AdvHMI components to frequently read data. I have tried decreasing poll rates (between 1000-10,000 ms) and I've used multiple drivers with large poll rate spreads. Some projects will run for a day or two with no issues, others will run only for several minutes. Sometimes, the components will simply stop updating with no warnings.

Are there general guidelines to maintain connection and avoid 'Read Failed' issues? Am I simply using too many components? I use Try-Catch blocks for all read-write attempts within my code. Any suggestions would be greatly appreciated. Thank you!

[Archie]

Do you see this on both the CLX and SLC driver? Does it only occur when you are reading with code or does it also occur on pre-built controls?

[astroman]

This occurs with both drivers. Would reading with code pose an issue? I have a number of components which depend on multiple tags (e.g. belt color is green when tags 1 and 2 are true, gray when only tag 1 is true, yellow when tag 2 is true, etc.). With the SLC driver, pre-built controls occasionally display the 'Read Failed' message. 

[Archie]

Reading with code can flood the driver especially asynchronous reads which can be requested faster than the PLC can respond.

[astroman]

Hm, I see. What would be the ideal way to evaluate conditions using multiple tags? I mentioned an example in which I may have 2 different tags (say Tag1 and Tag2) and a belt color depends on both conditions or one of the two being true.

For the moment, I have added additional DataSubscribers and I'm using the returned values within other DataSubscribers. Is this more efficient than reading tags directly?

[Archie]

Using subscriptions or Datasubscribers are best because the driver throttles the read rate to match what the PLC can keep up to.

[astroman]

Thank you very much Archie. I'll go ahead and modify my other projects and see how it goes.

[Archie]

If you haven't seen, the latest version allows you to specify multiple tags within a single DataSubscriber by using comma separated tags names in PLCAddressValue

[astroman]

By any chance, is there something else I could try? I'm no longer getting "Read failed" messages, but I am getting a frequent "No response from PLC(21)" message. Subsequently, the connection closes.

[Archie]

Are you using Ethernet communications? If so, can you run a Wireshark capture to catch the read failures? From that I will be able to tell more of the source of the problem.

[astroman]

Hi Archie. I ran the program for a while and I captured several logs while waiting for the message (much of the time, a good number of components were no longer updating). Here's one such log: http://www.uploadmb.com/dw.php?id=1423161475

Unfortunately, I paused the capture seconds before the connection closed. I  did, however, capture the message at the time of closing. The capture is No. 106. I've attached this Wireshark capture as a separate file (my PLC address is 10.2.27.55, for filtering purposes).

[Archie]

Here is what is happening:

Packet 774 - Request TH_2 at 17.781 seconds
Packet 785 - TCP attempts to re-transmit because there was no response at 17.082 seconds
Packet 786 - A response was received at 18.125 seconds (0.344 seconds later). By this time AdvancedHMI gave up and started a second try
Packet 787 - AdvancedHMI resends the request with the same Transaction ID at 18.125
Packet 790 - A response was received at 18.146 seconds

The AdvancedHMI driver has a 0.300 second timeout. Since it timed out, it prepared for a resend and simultaneously TCP performed a resend. Data came back from the first request and cleared it out of the queue. When the second response came back, it failed because it had nothing in the queue to match.

So I will made a patch that will not retry, but instead leave it up to TCP to handle retries and increase the timeout period. I will post the patch here shortly

[Archie]

Patch for the long response time

- Download and extract the attached file
- In your Solution, replace the file found in AdvancedHMIDrivers\Support with the extracted file
- Open your Solution in Visual Studio and perform a Rebuild All

[astroman]

Thank you very much Archie. I have swapped the files, but there appear to be some errors. I've attached a screenshot.

[Archie]

My mistake. The patch is actually for 3.97f, but it will work for 3.97e. Just delete every one of those lines with the error.