I may be being picky here, but I'm seeing about 0.4 sec blink every time I open a specific template and some weird behavior as well. Running 8.1.30.
This particular template has template parameter, "TagPath", which then feeds an indirect tag attached to a property, where the property equals {1}/Text and {1} is TagPath. The text in the object within the template is then bound to that indirect tag property.
So what I am seeing is that initially when the template loads, it will display whatever text was left in the indirect tag parameter, text, when it was saved in the designer, which was just test data. Tag quality then changes from good to uncertain initial value where the text value gets changed to none, before updating again and going back to good and the text gets changed to the target value.
To prevent the initial value from blinking with incorrect data and being an issue, I made it blank, but I don't like the blink that occurs during the changeover. It is intrusive because the object is loaded (it is a button in this case), but then the label for it is blank for a hot take then populated with a label.
Some things I've tried:
Altering scan classes of particular tags
Scripting to load initial values (helps, but still has some blink)
Scripting to load values and removing indirect tag (do not like in the event that the read fails)
I wouldn't ordinarily be worried about a half second here and there, but I use this particular strategy frequently and I would like to eliminate this issue if possible.
Consider creating a dummy (memory) tag that holds a None and the uncertain-initial value quality. (Construct a BasicQualifiedValue in a temporary script and write it to the memory tag.) Then ensure that your templates point at this tag before you save them.
The dummy variable combined with the initial write on componentRunning did the trick. Thank you so much!
Where can I get more information on these sorts of things (+related)? I don't think I ever would have figured it out on my own and I really wish that weren't the case.
For posterity:
I put this into the script console.
from com.inductiveautomation.ignition.common.model.values import BasicQualifiedValue, QualityCode
tagpath = "DUMMYTAGPATH"
uncertainTag = BasicQualifiedValue(None, QualityCode.Uncertain_InitialValue)
system.tag.writeBlocking([tagpath], [uncertainTag])
tag = system.tag.readBlocking([tagpath])
print (tag[0])
bound this tag to the internal property.
Then added this script to the template to immediately read in INTERNAL_PROPERTY from TAGPATH:
if (event.propertyName == "componentRunning" and event.newValue == True):
tagpath = "TAGPATH"
tag = system.tag.readBlocking([tagpath])
event.source.INTERNAL_PROPERTY= tag[0].value
I did not intend for you to have any runtime scripting. Simply that the tagpath stored in the template itself (saved in the designer) be this placeholder memory tag (perhaps set to read-only after initializing with null). So that any window that uses this template will be initialized with the same value the tag system delivers on binding initialization when the real value isn't ready yet. Which also means no propertyChange event at that point. The first propertyChange would be the one with the first real value.
No runtime script. Just some discipline in the designer when working on templates.
{ And, yes, it's a band-aid. For a wound unlikely to be healed any time soon. }
Maybe I’m executing this wrong, but the dummy tag alone does not do the trick. It just shows nothing for a short period of time. That being said, when logging the internal property, it shows its status going from good to uncertain back to good, skipping “none”, which is a solid improvement. I would have thought it would start as uncertain due to the initial state of the tag. The dummy tag still shows uncertain.
Could something like putting visibility on your templates until its tag bindings are good clean this up for you? Of course you would have to account for losing quality overlays with this visibility and have some other warning.
Right, expected. You aren't going to speed up the arrival of the data with these kinds of games, but you can eliminate the extra property change.
If the set of critical possible tag paths is small, and you don't mind a little extra runtime network traffic, consider using an empty client-side tag change event (just pass) with the tags in question in its subscription list. That'll get the request for subscription right at Vision startup and they'll stay fresh for any window that uses them.