In an ongoing effort to figure out exactly why the Groov Rio stops updating / reporting TCP modbus sensor values,
I’ve been tasked with causing repeatability with the error. Easier said than done. PLC side, I can interrupt the TCP Modbus, which causes the same issues. Rio side, I have no idea. So i was thinking our IO demand may be too great. but it TCP Modbus, doesnt fail reliably, it just seems to fail randomly.
So I set up a query, to poll modbus every 10ms, 1ms, 100ns. Well, latency seems to stay about the same on average, … about the same as the Main Scanner polling interval? something like 12ms, but with occasional , predictable spikes.
100ns is excessive? YES! but I cant wait around for this thing to fail randomly, and try to catch it being BS. So I’m willing to max this thing out a bit, Outside of blasting the Rio with EMP, I haven’t been able to deterministically cause the modbus to “stick”
Well I guess its not latency and timeouts. Probably not CPU Maxing either.
So Im thinking that whatever the system does to unload the CPU, maybe the TCP Modbus doesn’t wake the system in the same way other services like OptoMMP or a ping might.
maybe the CPU goes into an idle state. Maybe I should take it the other route:
poll once every 5 minutes or so.
