1. I have set up 10+ gateway timer scripts which runs every 1 second with a fixed delay. I can have my scripts run nonstop with no problem for weeks and months and then all of a sudden, 1-2 scripts just stop running while the others continue… no errors… nothing… only going into designer disabling and reenabling it will it continue to run again. why would this happen? is there any way to find out the cause? Is there an automatic way to get the script to run again if it sees this occur? This is like a rare scenario I see once in a month or so.
2. I also have gateway tag change scripts which fire when my tags go true. However, the first time in months did I see that when my tag goes true the gateway tag change scripts did not fire off. Maybe like the 20 tag change scripts were told to run, half of them did not fire off… the first time i’ve seen this happen of the many times it worked. is there a particular cause because i cant see any issues with the logs or cpu or memory. everything looked stable. so far i’ve set up logic to run on the gateway side if the tags do not fire off but what if the issue with the gateway timers happens on these scripts what more can be done?
3. also is there a way to keep the tags from firing off again when the gateway restarts? i added logic in my tag change scripts and gateway tag change scripts.
if not initialChange:
but when the main server goes down and backup comes up and vice versa the scripts do not fire again but when the main gateway restarts entirely and comes up all the scripts fire off again. is this the intended behavior of ignition? was thinking of saving data to the db but we are talking about thousands of tags.
our ignition has over 50k tags, hundreds if not thousands of tag change scripts, gateway tag change scripts, a couple of timer scripts, and lots of views, but the cpu and memory were very stable when these issues occurred. we have log files to catch errors but there was none to catch.
What version of Ignition are you running?
What are these tag scripts on the tags doing? They should be doing no blocking work (db interaction, system.tag.writeBlocking, http requests) to avoid bogging down the entire tag system.
In general as well, what are your timer scripts designed to do? What are your gateway tag change events designed to do?
Are your timer events set for dedicated or shared threading? If they are shared and one script is taking too long to complete, it may be blocking the others. What is your typical execution time for your scripts?
For your gateway events that are supposed to check for the transition of a tag to true state, you should look for the transition from low to high, something like
if not initialChange and previousValue and not previousValue.value and currentValue.value.
version 8.1.36
all the timer scripts are dedicated. and these timer finishes within <1 second.
i’ve seen all these scripts never take more than a second maybe max 2 seconds.
both gateway timers/scripts and tag browser scripts does db interactions and does write/read blockings as well. it reads certain data from the system either db or from other tags perform operations and writes back to the tags or logs events to another server.
but these have always been working without issues and just recently this occurred but now its working as intended again.
To add to this, tag change scripts can miss events very easily when tags change rapidly in a relatively short period.
I ran into this problem years ago and switched them all to gateway tag events. Tag change scripts missed events with just a few quick value changes. I tested the gateway event up to 75 changes and it didn't miss a single one.
To add to this, tag change scripts can miss events very easily when tags change rapidly in a relatively short period.
I ran into this problem years ago and switched them all to gateway tag events.
yes i can see that happening which was why i did set these as gateway tag change scripts and my logs told me that these tags went true and stayed true, the tag history tells me this too… but the gateway scripts did not fire off on the change from false to true which was what confused me the most.