HI, we have some PLCs that are on the other end of radio links and the current tags often blink to red (bad) status. What settings would I change so I can ride through those delays? Slow is fine, updating a couple times a minute is more than adequate.
thanks
What driver are you using? You may try setting those tags to a slower tag group so that they're not polled as often, but there's probably read timeouts you need to extend also.
the Allen-Bradley Logix Driver. I did try a slower polling but that didn't seem to help. I think you are correct, there is a timeout somewhere I need to change.
That would be in the driver settings. There's a timeout that's 2 seconds by default.
If you're still having issues, a better solution for slow radio links like that is to use Ignition Edge on the remote end and CirrusLink MQTT Engine and an MQTT broker on the server to use MQTT to push data rather than polling. It's more bandwidth efficient, too.
ok, thanks. Unfortunately I don't think I can retrofit 20+ sites I need to work with what I have.
I read that wrong.
I would recommend the things Michael Flagler suggested.
I would also try to confirm your radio signal is strong. A lot of things can impact radio signal.
the radio network is a given, it's been running for years. It's still a PITA and we have plenty of eyes on it.
What's the relationship between scan time and driver timeout? Do I want the timeout larger or smaller than the scan time?
Scan time is the rate the OPC driver is polling the device.
Timeout is how long you have till it says it's bad.
Certain conditions can cause it to get a bad read from overloading the comms on the PLC side but I don't think you'll be able to cause that problem over a radio network. It's a thing that can happen but I don't think it's your problem.
I would recommend setting up a longer polling rate on your tag groups. You configure tag groups by clicking the drop down in the tag browser and selecting "Edit Tag Groups". This lets you make a custom tag group that polls slower. Then you can mass edit tags to assign them to the slow polling group.
There's a tradeoff.
You get timeouts when requests are dropped. For typical raw protocols, you won't get a retry until you have a timeout.
It really matters what the protocol is. If Modbus RTU or other serial protocol over the radio, you probably cannot eliminate the overlays, as you cannot detect a single-packet problem without a timeout. In that case, a short timeout is best, as it will keep one timeout from killing other requests (like dominoes falling).
If layering on top of TCP, which natively does retries, the timeout should be longer than TCP's ordinary retries. But that may be too long for your process. (Common problem with TCP-based protocols.)
I wish there was a simple answer, but there's not. Slow is slow. Sorry.