How exactly are update rates determined (from PLC to OPC) when taking a tag directly from the ‘device’ in a project and putting in a database? Is it controlled via the transaction groups update rate?
What I’ve noticed (for a Modbus device anyway) is that if too many tags are set to update to quickly, timeout error begin to occur. Is there a way to optimize communications? How does the OPC server optimize comms?
I haven’t had any problem with the Etherenet IP comms, but only began noticing some possible limitations when using ModbusTCP, but this may be device specific too.
Kurt
Ultimately, the rate at which a driver requests a given address be updated is equal to the fastest rate of any scan classes containing a SQLTag that points to that address.
The OPC-UA server has a setting called “Stale Threshold”, which is essentially a multiplier applied to the rate of any given item subscribed on a driver. If in reality, a driver is updating a tag at a slower rate than (lowest rate * stale threshold), the server sets the quality of that tag to stale.
At some point on any device you can reach a point where you’re asking for too many tags at too fast a rate and its inability to keep up reaches the calculated threshold. The cheaper/older/slower the device, as many Modbus devices tend to be, the faster you’ll eventually reach this point.
Looking at the Diagnostics page for any given device can provide a lot of insight to what you’re currently asking of a device and what its current response times and delays are.
In a case where I’m not specifically using a SQL Tag (i.e. reading directly from a device into a database) what controls the update rate?
How are you reading it, through a scripting call?
No, through the gateway: Dragging a tag from the device to a transaction group. Not creating a separate SQL Tag.
Oh oh I see. Groups. Got it.
Then the tag is subscribed at the groups execution rate, unless you’ve overridden the subscription rate in the options tab. Everything else works the same as if it were in a scan class.