Scanclass max speed

Hi All,

I’m looking for knowing the max speed at tags can be read/write.
Just to be sure, the parameter I’m checking is: " Slow Rate Scanclass ( assuming to use direct mode )"
Assuming I have an autoincrement ( every 100ms ) tag inside the PLC, if I set the Slow Rate to 100ms and display that tag, I can’t see it update every 100ms. but more or less around 200/300ms.
Another info I would like to know is: Does make any sense to create various Scanclasses at a different Slow Rate ( one at 100, another one at 120, another one at 130 and so on ) for improving speed, in order to have
asynchronous read call?
Are there any other parameters I have to check?

Thank you very much for your time.

Try changing the Client Poll Rate: Project Properties - Ignition User Manual 7.9 - Ignition Documentation

I'm not 100% sure what you're asking here, but usually when someone asks if they should stagger subscription rates based on some scheme like prime numbers or whatever else the answer is just "no".


It's is already at 100ms.

But this is not an issue of some kind, I'm just looking to know which is the max speed at a tag can be read/write with, for example, the Siemens driver. I was hoping in someone sharing their experience :sweat_smile:

It depends on load. Look at the actual statistics for the specific device, particularly the average response time. That's the round trip request from Ignition/response from PLC. Then look at the load factor. Anything close to or above 100% means there's not enough bandwidth (somewhere, usually the PLC) to satisfy all of the subscriptions at the requested pace (scan classes), slowing everything down. The more tags monitored, the slower it all gets.
You can use the system.opc.* functions to inject additional requests on demand -- those will perturb the statistics when used, but will execute as soon as possible. Round trip times from a gateway script using these functions will be notably faster than from a client script, of course.

1 Like

Sorry, but which is the difference between system.opc.readValue / writeValue and system.tag.write / read?

"Tags" are Ignition's gateway-internal data monitoring objects. OPC "Items" are addresses understood by an OPC server to access external data. Ignition's OPC Tags are gateway-internal data monitoring objects that are subscribed to an OPC server's item address. Ignition receives external changes to that item from the OPC server and passes them on to Vision windows' property bindings, tag events, tag changes scripts, etc. Writes to the OPC Tag from the Ignition side are passed to the OPC server.
The system.tag.* functions work with Ignition's internal data monitoring objects, including non-OPC objects like memory tags and expression tags. The system.opc.* functions bypass all internal data objects and go directly to the OPC server to read or write an external value.
OPC Tags are subscribed with a requested update pace from the tag's scan class. This causes the OPC server to produce regular read requests to the external device to obtain the current data. Good drivers for OPC servers optimize multiple subscriptions to adjacent or nearly-adjacent PLC data items into combined requests, depending on the protocol's flexibility. The calls to system.opc.* are not part of subscriptions, so are generally not mixed with other requests.

Some confusion occurs because OPC Items -- the addresses -- are often called OPC Tags, since they generally point at external data that is in fact a PLC Tag. I try hard to use "Item" in the right places. /-:

1 Like

Thanks for the explanation!

Sorry to bother you again :sweat_smile: I swear is the last question… on this post :wink:
Do you know if a system.tag.write or system.opc.writeValue function is called when I change value inside an input field ( like ‘Text Field’) if the input field has a tag associated with it?

Any binding is going to perform a write through the tag system, which will eventually delegate to the OPC server (if needed) and send an OPC write.

1 Like

Thank you so much for the answer! :relaxed: