Memory Tag Value Changed Event Fires on Startup/Creation with initialChange=True and Uncertain_InitialValue Previous Value

Ignition
1

Hi everyone,

I'm trying to understand some behavior I'm observing with Memory Tags and Tag Event Scripts (Value Changed) in Ignition 8.1.

Test Setup

I created a new Boolean Memory Tag with a Value Changed script:

logger = system.util.getLogger("testmemTag")

logger.info(str(initialChange))
logger.info(str(previousValue))
logger.info(str(currentValue))

I did not change the tag value after creating the tag.

Logs Observed

Immediately after creating the tag:

[null, Uncertain_InitialValue, Thu Jul 02 12:38:36 UTC 2026]
[false, Good, Thu Jul 02 12:38:36 UTC 2026]

Then another event:

True
[false, Good, Thu Jul 02 12:38:36 UTC 2026]
[false, Good, Thu Jul 02 12:38:36 UTC 2026]

No actual value change occurred.

Similar Behavior After Gateway Restart

On another Memory Tag, after a Gateway restart, the Value Changed script logs:

previousValue = [null, Uncertain_InitialValue]
currentValue  = [true, Good]

followed by another invocation where:

previousValue = [true, Good]
currentValue  = [true, Good]

Again, no actual change in the Memory Tag value.

Questions

1. Is this expected behavior for Tag Event Scripts?

Can a Value Changed script on a tag be invoked during:

  • Tag creation?
  • Tag initialization?
  • Gateway startup?
  • Provider restart?

even when the underlying value does not actually change?

2. What exactly does initialChange mean in a Tag Event Script?

The documentation says it is intended to indicate initialization, but I'm unclear on:

  • Why there can be multiple invocations with initialChange=True
  • Whether it is guaranteed that the first real value transition will have initialChange=False

3. Is previousValue = [null, Uncertain_InitialValue] the expected startup state?

In my tests, the current value is already:

Good

while only the previous value is:

null
Uncertain_InitialValue

Is this the normal way Ignition represents the initialization event?

4. Recommended Pattern to Ignore Startup Events?

If the requirement is:

"Do not execute business logic during Gateway startup or tag initialization, but do execute on the first genuine value change."

which pattern is recommended?

Option A:

if initialChange:
    return

Option B:

if not previousValue.quality.isGood():
    return

Option C:

if previousValue.value is None:
    return

Option D:

if initialChange or previousValue.value == currentValue.value:
    return

5. Any Known Differences for Memory Tags?

Is there any special behavior for Memory Tags regarding:

  • Restoring persisted values on startup
  • Tag event execution during restoration
  • Multiple initialization events

compared to OPC or Expression Tags?

I'm mainly looking for the most reliable way to prevent startup-triggered executions while ensuring the first real tag change is never missed.

Thanks!

2

  1. Yes, to all.

  2. The initialChange flag means the infrastructure has had a gap in attention (long or short) and doesn't know, for sure, what the previous value really is. For memory tags, it is initialized from the value storage, but might be out of date. You are not guaranteed that the first "real" value change has initialChange false.

  3. No. For other than memory tags, previousValue is entirely null on startup/tag restart. Memory tags try to start up from value storage, if possible. You really should not even touch previousValue when initialChange is true.

  4. None of the above. When initialChange is true, you must determine from your own recordings, what the previous value was as far as your business logic is concerned. This may require time-consuming DB or historian or API calls that can be avoided when initialChange is false.

  5. Yes, memory tags have a value storage system, that tries to capture all writes, but obviously cannot guarantee it. If your gateway shuts down or fails over to a redundant backup right after a memory tag write, it may be lost.

If you have business logic that absolutely has to note changes reliably, you need to use a high-availability DB as the source of truth.