to prevent the script running after a script change or tag change. And it works well for this. If I don’t use this, the script will run when it shouldn’t.
However, if the gateway is restarted, it also prevents the script running the first time its triggered. In this case I do want it to fire, and this is causing problems. Subsequent triggers run fine after this.
For example, if the gateway is restarted and 4 hours later the event is triggered for the first time since the restart, the initialChange line will prevent it from running.
How do I prevent it running on a script change or tag change, and allow it to run the first time it’s triggered after a gateway restart?
Not sure if this is a bug or not. Still talking to support about it.
But in the meantime, to get around this issues the following works:
Create an additional memory tag to store the last value of the trigger.
Use this to test if it is the same as the trigger value, instead of using the initialChange flag.
E.g. instead of this:
if newValue.value == 1:
if not initialChange:
#[run code here]
use this:
# read memory flag
tagPath = '[default]MemoryFlag'
flag = system.tag.readBlocking([tagPath])[0].value
if newValue.value == 1:
if newValue.value != flag:
#[run code here]
# update memory flag
if newValue.value == 1 and flag == 0:
system.tag.writeAsync([tagPath],[1])
elif newValue.value == 0 and flag == 1:
system.tag.writeAsync([tagPath],[0])
This works in all cases I’ve tested and is how I expected the initialChange flag to work. But it requires a bit more effort.
I make it a practice to read through this group and use advice like David’s in my scripts, as a “good practice” (regardless of whether a bug bit me or not).
Each time you toggle the TestTag from 0 to 1, all three prints should appear in the wrapper.log.
If you clear the TestTag, restart the gateway, then set the TestTag to 1: if it has this problem then you will only see print 1 and 2. If there is no problem you should see print 1,2 and 3.
Did you ever get this resolved with support?
I'm experiencing the same issue in 8.1.18. Tested it in a clean installation and have found it only occurs with the Default tag group. Creating a new tag group identical to the default and the issue goes away.
Hi Tom,
Didn't get it fixed by support and still using the work around code. Not sure if newer versions have the same problem. The work around code works so well I just left it. Good to know about creating a new tag group.
Hi Fernando,
That will probably work too. I'll stick to my solution for now as it's more explicit and I find it easier to understand. One issue with the bootFlag is that if this is a bug, as suggested, and fixed at some point, then scripts will start triggering on startup when they are not supposed to.
Good point. It is surprising that the ignition team does not take a position on this issue. If this is the expected performance, they should at least specify it in the documentation. In our plant this has caused problems; it is not possible to design systems reliably in this way.
I think you are reading too much into the supposed meaning of the initialChange flag. Fundamentally, it is a signal from Ignition saying something like "I just woke up, don't know what was going on while I slept/dozed/crashed, and you should double check the following values." Simply put, this isn't a bug.
Ignition is pretty good about identifying and passing on valid change while running, but simply cannot do so upon startup or project edit. Using another form of state storage is entirely appropriate.
