I am doing tag change scripts 2 ways.
- Adding a script on tag value change on the gateway.
- Adding a script on tag value change on the tags itself.
I want to know would keeping all the scripts on the gateway lead to better performance and memory usage. If yes, how?
Right now, I have ~600 tag change scripts on the gateway and maybe double that on the tag browser.
So far, the advantage of moving to gateway I see is being able to debug and see the status(success vs error) of these tags on the gateway.
Always use gateway tag change events. Put in effort to make similar change events generic, so you can handle more tags with fewer defined events.
Tag value change events execute in a limited thread pool (default 3 threads) and any delay will affect the entire tag system. Gateway tag change events can share threads or spawn a dedicated thread.
No blocking work (polling a db or http endpoint, even a blocking tag write) should ever be done in a tag value change event, and every event should complete in <10ms to avoid impacting the system.
If you are doing a simple calculation or writing a tag value from one to another(use writeAsync), you should be fine. Anything past that should be using a Gateway Tag Change Event.
Could you elaborate more on what exactly you are doing in these events? (Rough outline is sufficient)
2 Likes
The events updates other tags which i have a couple of gateway timer scripts using these tags to do some calculations and sending it back to the tags.
Like a using ignition as a scada platform.
What are you updating and calculating? Runtime stats? Are these calculations all one-off or can you make them generic? Are these calculations unable to be achieved via expressions or expression tags?
1200 tag value change events seems excessive, what is the size of your system? (number of devices/estimated total tag count)
All I can say is BIG... HUGE system. Yes both calculating stuff from the PLC's, other systems... Scripts run based on certain events happening in system....
We do have some expression tags but no, these are taking multiple inputs (tags) performing some calculations to decide what to write to other tags...
I am working on over 17k tags, the entire system has over 100k...
Got it, in that case 1200 makes sense. Best bet is to try to make as many gateway tag change scripts generic so they can be re-used.
Also tag value change events are only able to access the global scripting project, while Gateway Tag Change events are able to access the library of whatever project they are defined in.
A follow up on this, lets say if I have 100K tag change scripts would it be better to make 100K gateway tag change scripts which monitors each tag, or just 1 gateway tag change script which monitors all 100k.
If lets say all 100k tag changes, the individual will fire off all 100k scripts but will the 1 gateway tag change script fire off 1 and start checking from top down or will it also fire off 100k of these scripts.
if this happened, the single script listening for 100k tags would fire them all off using a queue, where only one execution at a time takes place.
if you had 100k individual tag change scripts defined, you'd suddenly have 100k threads executing 100k scripts in parallel, and your Ignition Gateway would probably crash.
1 Like
You don't need 100K gateway tag change scripts. Fortunately the Tag Path(s) support wildcards. When I moved my scripts from individual to gateway, I used the wildcard to invoke an intermediary script that checks the tag path, and executes whichever script corresponds to it.
1 Like
Is there like a max number of threads a gateway can create and run scripts before the system starts to overload?
I have about 20-30 gateway timer scripts which runs every about every 1 second fixed delay on its own dedicated thread.
Then we have a lot of tag change scripts... (will be reduce to have a few scripts monitoring multiple tags).
I want to know is there like a max thread that ignition has by default before things start to overload?
No, any max number of threads would depend mostly on available memory / hardware resources. There is no artificial limit in place.