Ignition 8.1.2 - ManagedTag doesn't accept update value in the past

@PGriffith, @Colby.Clegg,
We use a ManagedTag provider for a replay module.

Before Ignition 8.1.2 we was able to update tag value as for example:

  • Path/To/TagA : Value 1 / Quality 1 / Timestamp1
  • Path/To/TagA : Value 2 / Quality 2 / Timestamp2
    with Timestamp2 < Timestamp1

With Ignition 8.1.2

  • Path/To/TagA : Value 1 / Quality 1 / Timestamp1
  • Path/To/TagA : Value 2 / Quality 2 / Timestamp2
    When Timestamp2 < Timestamp1, Value 2 is Ignored and Path/To/TagA keep Value 1 !

Is this change deliberate ?

@Colby.Clegg can explain in more detail, but I believe it was deliberate, something to do with supporting replay or bulk application of buffered values. It’s important that value changes are ordered.

Today is a holiday so I’m not sure you’ll get a response from him or not.

1 Like

Hi,

Yes, this was a deliberate change. Here’s the entry from the change log:

Improves the handling of out-of-order data in tags. When outside data, such as OPC or tag references, arrives with timestamps that are out of sequence, the data will be processed by the history system, instead of being ignored.

So the case we were trying to handle is that apparently in some cases, coming from outside OPC servers with buffering, the latest value is delivered before older values are passed through. The tag system previously would publish each change, as you saw, however, the history system would always ignore those values.

This change marks those values as “backfill” values, and processes them through history, but does not publish them. That way, the latest timestamp seen is always represented as the current value.

With that in mind, you might prefer the new methodology. Perhaps you need to have a small buffer and order the values yourself. But if you truly prefer the previous behavior, there is a system parameter you can add to ignition.conf to revert the behavior:
-Dignition.tags.processbackfill=true

Also, I think you DM’d me (or have a different post) about something else that may have changed in this version, that I’ve been meaning to look at: in 8.1.2, if you have 0 deadband, it will now publish a new value if the timestamp has changed. The motivation for this is that it is the source that should dictate changes, and the tag should not prevent them, especially if the deadband is 0. On the other hand, we adjusted it so that even a small deadband (.1, for example), which previously would not have had an effect on Integers, will now filter those timestamp based changes.

I still want to look at your actual question, though, because I think it has to do with Tag Group based expression execution, and so perhaps in that case, the “source” should not fire events if the value hasn’t changed. I’ll let you know.

Thanks a lot for these explanation !
The change for the first item make sens. It was just a bit disturbing for my use case, but I finally found a workaround by adding another timestamp property to the tag of the managed tag provider.

The second item, was the update of the timestamp/lastchange property with no value change ostensibly. I will check if the deadband is 0, and put 0.1 for integer and boolean value in order the timestamp field can display the lastchange value timestamping.

I’ve tested a deaband with 0.1 for boolean, but the tag timestamp change every second despide the state is True or False and doesn’t change.

Some example:

Ok, I’ll take a look. Maybe the change didn’t apply correctly to booleans.

Hi @Colby.Clegg, do you find anything about booleans tags ?