Using if not initialChange: works perfectly in normal operation. However, our IT department reboots the Ignition VM about every two weeks for Windows updates or other maintenance. Unfortunately, this is company policy, so I cannot keep the server on a separate VM that they do not touch.
After every reboot, the first execution of every Tag Change Script is considered initialChange == True, so any script using if not initialChange: will not run on that first real value change.
Right now I see two possible solutions:
Manually trigger all required scripts after startup.
Add a Gateway Startup Script that performs a first "dry run" or initializes the tags so the next real change is not treated as the first execution.
The first option is not really practical because this is a large plant with thousands of Tag Change Scripts.
The second option works, but before I implement it everywhere I wanted to ask if there is a better or more standard approach.
Has anyone dealt with this issue in a large system? Is there a recommended pattern for handling initialChange after planned gateway/VM restarts?
For example, would it be better to:
Keep using not initialChange and add startup initialization logic?
Use previousValue.value != newValue.value instead?
Store a separate "GatewayReady" memory tag and ignore initialChange completely once the gateway is fully up?
Or something else?
I only started noticing this because IT recently began rebooting the VM every two weeks. Before that, when it only happened once a year, it was not really a problem.
You are misunderstanding initialChange. It means Ignition does not know if the value supplied is an actual change. (It cannot know on startup.) An application that depends on catching all value changes must include code to retrieve prior information from your database or historian when initialChange is True. And then decide on its own if previousValue != currentValue.
There is no magic wand.
Also, it is, in my not-so-humble opinion, engineering malpractice to use Windows in a critical plant-floor application. IT breaking your system every so often for forced updates is ridiculous.
In a 100,000-employee corporation, there are some battles you just can’t win. One of them is stopping IT from pushing “security upgrades” every two weeks. Unfortunately, Automation & Controls already lost that one.
And yes, you are right — my idea of forcing execution with a test tag would not actually solve the issue, because it would only reset that test tag. That was my mistake.
So the problem remains the same: after every reboot, the first tag change is always received with initialChange == True.
I tested this several times on my local machine with a very simple script, and the behavior was consistent every time: the first change after restart is always treated as an initial change.
