There's nothing we can do to change this. It looks like you're already down to a bare minimum of requests for each device: the connect request plus only a couple read requests per poll.
Like I said, this is being exacerbated by the frequent disconnects. ANY time the connection is severed the tags quality goes bad. Polled reading makes this worse, but there's still scenarios in subscribe mode where this could happen as well. On a 60s scan class the server is only going to evaluate the items and send back the latest value every 60s, which could very well be bad quality if the connection went out after the last successful read from the device and before the subscription on the server came around to evaluate again.
The real problem is that a low-reliability, low-bandwidth network like this was not in mind when our current drivers were being designed. Handling this kind of situation gracefully would require a handful of specialized logic for this scenario, and the drivers were designed to be more generally applicable.
They are ML100s. The only other comms are 3 messages between two of the PLCs sent sequentially once per minute. We’ve already tried the prime number thing with the scan time.
Kevin,
A little disappointed there is not more we can do to control the polling. We’ll continue to work on the causes of the connection problem but congestion due to the lack of traffic control is a contributing factor.
It appears everyone else has high-bandwidth/high-reliability networks to work on.
After we finish our current development push (7.6, alarming), we’ll be doing another short polish phase (7.7). I’ll see if it’s possible to do some work with our drivers that might make life easier when using these kinds of connections. There’s a few other ideas for general driver improvements that I want to explore, so adding this to the list might be possible.
Until then, I’m out of ideas, but if anybody else has some suggestions they’re welcome to step in
Just putting it out there that we are also having issues with our low bandwidth networks.
In our case it is SLC 5/04s on DH+ behind a controllogix gateway. Seems that quite often a node will fail to connect for quite some time. Is most pronounced after a server restart.
