What is the difference between the tag change configuration at the point and the gateway

Ignition
1

What is the difference between the tag change configured in the point and the gateway, what is the maximum number of points configured in the point, what is the upper limit of the number of points configured in the gateway, and what is the maximum number of points configured in each gateway event

2

I don't understand what a "point" is, that isn't Ignition terminology. I assume you mean what is the difference between a tag value change script (configured on the tag) and a Gateway Tag Change event.

There are several differences, but the two most important in my mind are:

  1. Tag value change scripts execute from a thread pool that is limited to 3 threads, once that limit is hit all other changes are forced to wait until a thread is available. If you have scripts that are longer than the time between changes of any tag with a script configured this can lead to missed events. Gateway Tag Change scripts do not have this restriction.

  2. Gateway Tag Change events are not "missed" only delayed. (As far as I know).

I don't understand what this means, can you clarify your question?

Do you mean how many tags can you configure? It's unlimited by the software, so you are only limited by what your hardware can handle. There are active installations with millions of tags in a system.

Gateway Tag Change Events are configured by scripts. Each event has a single script, an unlimited amount of tags can be configured to trigger each event. Again you will be limited by the hardware available. At some point you will exhaust what is available to you and then you're events will be delayed in being processed.

1 Like
3

Extra clarification:

  • There are no software-imposed limits in standard Ignition for these items.

  • There are consequences to overloading either type of change event:

  1. If you write event scripts on tags without regard for how quickly they need to run, as soon as you have three running in parallel, all others in the whole gateway cannot run. If more tag changes are happening while the three scripts are blocking others, some tags are likely to overload their 5-entry event queue and start missing events. These events should never do anything that takes more than single-digit milliseconds (or less in large systems). That means only store-and-forward database operations and no operations that require a network message exchange of any kind.

  2. If you configure so many tags on a gateway change event that the script cannot keep up, it's unlimited queue will use more and more memory. You risk running out of gateway memory and crashing the whole gateway. These event scripts can run more time-consuming actions, as long as they keep up on average.

For (1), there is a startup configuration parameter that can set a larger thread pool, but that is just a band-aid for anything but massively multi-core servers.

2 Likes