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.
We are having a similar problem, and it is specific to Memory tags. I have a theory on why this happens, although I would need some help from someone with deeper knowledge of how Ignition works to know if this is true.
For an OPC tag, I suspect that the default value of the tag is essentially null until the tag is read by Ignition for the first time. When that first read tags place, the value of the OPC tag within the Tag Browser essentially changes from null to whatever the actual value of the tag is, and the event executes.
However, for a Memory tag, I suspect that the value does not change following a reboot since the tag is basically a value in a SQLite database. As a result, when the event script executes for the first time after the gateway has been restarted, it is the first execution of the script and therefore exits intentionally because of the
if not initialChange:
line. It would be really nice if someone from IA could confirm this so we can know for future reference.
@DavidWisely Can you confirm if the original tag for your Gateway Tag Change Event Script is a Memory tag?
Yes, this is related to what I was trying to say. I don't think the Gateway Tag Change Event executes when the tag starts up for Memory tags. As a result, the first execution of the Event is when the actual value of the Memory tag changes. However, for an OPC tag, the first execution of the Event is when the tag is read for the first time because, at the time of the Tag starting up, the OPC tag did not have a current value.
I think I've been able to confirm my hypothesis, although I don't know exactly why it works this way. On a fresh gateway, I set up two different Gateway Tag Change Event Scripts. For one event, I used a memory tag for the trigger, and the other event used a PLC/OPC tag. After a restart of the gateway, the event for the PLC/OPC tag executes as soon as the initial read of the tag takes place, but the event with the memory tag for the trigger does not execute until the tag actually changes.
I'm only guessing, but I could see how an initial change for a memory tag would only occur at creation. As by design the value is persistent in the Internal DB, so since they know that the last value is "correct" then there is no need to set initial change flag, however, with OPC, that value would be "uncertain".
