I appreciate quick and honest answer, I do understand the difficulty to recreate the problem.
The remote PLC is on a wireless link that used to be very good, but now has some issues (New buildings built in the last year or two).
While the site generally works well, it does get latency and dropped packets. So the low quality of the link is very likely the cause of the problem.
The other four remote units (all DL-06 /w ECOM100) are also wireless, but have not seen same loss of network.
As for the ability to cycle power on the unit, this is not a solution that is reasonable. This unit has a hardwired connection for controlling a water well/pump, so the outputs dropping out will also interrupt that process.
For me, finding the reason the Success/Error bits do not update would be the first check. On a device failure/hang, the error bit should at least be on. When this happens, both remain false. We changed our communications health detection to use a rising edge Success and heartbeat (pseudorandom and analog input; make sure PLC is in run mode) from remote unit.
The DST40 & 41 (Added all $Eth items) are now on our list of things to watch, but would these be from ALL ethernet devices? Currently, these are at 0 for each for the last 10 hours.
80ms scan time? That's pretty stout. It shouldn't hurt anything, but high scan times are never helpful for comm. Is it always that high?
It wouldn't require power cycling, just invoking the REBOOT instruction, but it will interrupt the outputs.
The instruction is clearly not working right if it's never timing out. It's a joke here at Host, and I mean no disrespect with this, but when there is a failure in the controller and the mode of failure doesn't satisfy someone, my response is generally "what about 'exception condition' do you not understand?" The bottom line is it shouldn't be happening, and we make every effort to keep things from happening, but bugs are bugs and they don't always behave the way we want them to behave...cause they're bugs.
Given the unstable link, I'm now at 90% confidence this is a network stack resource issue. Wondering if some of the low level networking code isn't accepting a missing/unavailable resource as a valid basis for timing out. That isn't great and shouldn't happen, but when is it ever OK to run out of memory? Never. Exception. If it is that, I would expect ST145 and/or ST146 to be on. They indicate that when the Ethernet hardware is trying to inject a packet into the stack, there were no free buffers. That generally should never happen. While that by itself shouldn't cause something else to hang, I'm wondering if there is some pregnant moment in the TCP stack that's causing a low level hang up.
DST40 and DST41 count up in response to excessive packet loads. They aren't problems necessarily, but they give a glimpse into whether there are packet bursts happening that could be causing issues.
I'll put some thought into this to see if I can come with reasons this might be happening and hopefully some diagnostic checks that would let us see what might be going on.
Topic: BRX Looses Comms, No response to DmD, Modbus TCP (Read 34321 times)