Tag Change Scripts and initialChange After Frequent Gateway Reboots

Ignition
1

Hi all,

I have a small issue related to initialChange.

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:

  1. Manually trigger all required scripts after startup.

  2. 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.

Thanks!

2

Just an idea, have you tried for example with:

if previousValue.value != newValue.value and currentValue.value:

in this case you should trigger with a new valid value.

3

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.

4

previousValue is None in some instances and therefore has no value prop so this will cause an exception

1 Like