Ignition 8.1.2
We display path/to/tag.lastchange (inherited from 7.9/8.0) in some bindings.
For gateway’s expression tag (with Tag Group Execution mode), lastchange tag property is updated every times Tag group is executed instead of when the tag value really change !
Seems to be a bug.
Lastchange seem to be considered like Timestamp property
The old LastChange tag prop is just aliased to the Timestamp property. When you use Tag Group Execution Mode something about the value (a value is Value, Quality, and Timestamp) changes every time the expression is forced to evaluate.
In my use case, I have 2 tags:
PATH1/TS/ETAT_PORT is an Integer expression tag
jsonGet(toString({[.]../_intern/IF_TABLE}),"['Ethernet0/0/0']['_1_3_6_1_2_1_2_2_1_8']")
When I check in the tag browser : V,Q,T doesn’t change.
PATH1/TA/ETAT_PORT is a boolean expression tag
if(tag(concat("[default]",replace({PathToTag},"TA/DEF_PORT","TS/ETAT_PORT")))!=1,True,False)
When I check in the tag browser : Timestamp change every second.
I’m not sure it was the case in 8.1.1…
Do you think it could be possible to change the Lastchange tag property to reflect a true “lastchange” ?
I’ve observed a similar change for memory tags (boolean only) that occurred between 8.1.1 and 8.1.2. I had a gateway timer script with a section that wrote true to a boolean tag, but found that each repeated write of true resulted in a new timestamp for that tag, instead of the timestamp being when the tag value first changed from false to true.
My tests with integer memory tags in 8.1.2 showed no change in behavior from 8.1.1 (as far as I am aware).
OK, we’re trying to get this cleaned up for 8.1.3 today. We’re going to tweak it so that a non-0 deadband on any data type will filter time-only changes.
8.1.2 did change this, as part of an effort to better support out-of-order data delivery to tags (which is happening more and more as we support different underlying systems with data buffers). Long story short, it was decided that if a tag’s value source publishes a change, and the config of the tag (namely deadband) allows the value, we shouldn’t then filter it again at the subscription layer. The default deadband value of 0.001 should have prevented any change for most tags, but that deadband wasn’t applied for non-numeric tags. We did tweak the logic for integers in 8.1.2 (previously the .001 deadband was basically treated as “deadband=off”, because an integer can’t change like that), but we didn’t include other data types.
There’s still some debate about how this all should work, and if the original decision was sound or not, but at least this should give you a way to control what’s happening, and should be consistent upon upgrade in most cases.