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.
I would recommend contacting our Product Support team as well, they can assist you with direct troubleshooting.
Phone: 951-695-3080
Email: support@opto22.com
What is the Modbus client that you are using to access the RIO? Is anything other service running on the RIO? Have you looked at the log files for anything out of the ordinary?
Hi Greichert,
I started there, and its on going. Figured I would poke the community as well.
Seems at least a few folks have encountered the issue, not sure if anyone has a direct cause.
Im talking with another member in my team about it, who seems to think UDP spamming broadcast addresses keeps the RIO alive. .. which I mean, you know how it sounds.
But I have to look in to everything now, because my best guesses were not right.
When we first encountered this issue 9 months ago,
we concluded that the (a) source was Electro Magnetic Interference, effecting the Modbus. Using a grill lighter I was at the time fairly reliably triggering the event where
IO gets stuck in the last known state, and reports inaccurate values.
Updating the firmware did seem to help, but in our deployments, a compressor contractor when closing was measured to be outputting 2000uT, and the field issues remained. In part, due to our in field network configuration:
[PLC]→[Rio]→[HMI]
which makes updating the Rio Firmware virtually impossible remotely.
Well back in testing, I took a microwave transformer, and cut off the secondary winding, to create a EMI generating 2000uT. Frimware update or not, I was able to fairly reliably interupt the TCP Modbus Connection.
OK sure, its undesirable to have the EMP, but there not much I can do about that remotely. The real issue we have is that the TCP Modbus retains and reports sensors as the last values read, and never re initializes the connection. Every thing fails. Our job as controls engineers is to make sure when it fails, it does so safely.
Enter OptoMMP.
Well it was a pain in the butt to write PLC code to generate and send OptoMMP commands, but it was ultimately do able. When OptoMMP fails, from an EMP,
the values are not retained. This allows our other systems to process the state, and programmatically in a more safe and reliable manner.
This post would be better with pictures.
No more Stale Values.
1 Like
