Yes, that is one reason. But not the only reason.
This is easy to monitor and proactively adjust hardware resources. And easy to explain to a pointy-haired-boss after they decline to spend the money.
Compared to checking the missed event flag in every single script just in case you land in a tight corner and data mysteriously doesn't get recorded or state machines mysteriously get into strange states. Uh huh. Not for me, thank you very much.
@pturmel The client I am doing this for is a multi-billion $$ business and they still send us Autocad drawings made with a pirated version of the Student Edition.
Totally understand. Depends on your needs.
When the queue starts overflowing the oldest events are discarded, so you eventually execute with the most recent set of values up to the current value. For some applications this is okay, others it might not be.
@pturmel converted me to gateway tag change event scripts
Tag Value Change Scripts: Are They Run Asynchronously? - Ignition - Inductive Automation Forum
And there is no way to extend this queue?
In my case the event change signals the completion of a task. The machine has written its final values and is now waiting for the next command. As such I can easily accept a 1 or 2 or 3 second delay before the data is actually recorded in the DB.
And because each task is unique, I can’t just use the values of the latest event.
Note I only skimmed this topic, that pertains to tag events so may not apply to the gateway limit
This is significant. If the event can't fire until the machine runs another cycle, and the command to run another cycle is part of or otherwise linked to the data recording you do in your event script, then the architecture itself prevents more than one event being "in flight". Effectively, that is a handshake. That one almost certainly can be defined on the tag (in the UDT).
If you have events that record data repetitively and relatively quickly during a machine cycle, that's where you can get trouble. Also note my advice in the post @dkhayes linked: anything over single digit milliseconds is just too long for an event defined on a tag. Even if you don't have a problem with that tag, you could push another tag's requirements over the edge.
IMNSHO, tag events have too much opportunity to interfere with each other to handle any complicated task. Use gateway tag change events for anything important.
The machine commands aren’t linked to my data recording. So the machine will happily start the next command without me recording the data from the just finished command. Murphy says that this will occur with enough machines being monitored which will eventually lead to an event missed situation.
I do record repetitive data, but that is handled by a GW Timer script.
I guess I should add a third goal of being more robust in my recording of data.
And I believe all of my scripts are running in single digit ms