We have a problem with a lot of our forms that we just noticed regarding indirect tags.
We are running FPMI 3.3.1 (due to deployment problems we encountered when upgraded to latest version which might be related to signature on reporting plugin) and also did some testing with Ignition 7.0.8 to see if it happens there as well (which it does).
First some background, we have many devices that are identical in nature and share many tags so we use indirect tags to alter the front part of the path to switch between the different devices.
We add dynamic properties to the root container (or at least a container) that holds the current selection and the combobox will update that dynamic property. All control properties are mapped using standard indirect tag binding.
On the Open event script of the window it will validate if the currently saved dynamic property is really in the database and if not default it to a different value that is present. (This is currently mostly because my test system has a different device list than production.) I think the activate window script will also do this validation. Don’t think these scripts are affecting behavior but we see the problem when this script fixes the incorrect devices.
Also we might open these forms from a button on another form which has the device already select. We then open the new window and change the dynamic property to the correct device as part of the action script that opens the window.
So the problem is that some times the tag values are not correct tags. So they are actually showing the values from a different device. Presumably either the values from when the form was saved or the values associated with the dynamic property as it was saved. Normally the problem only occurs when the form is first loaded but can happen if its unloaded from form cache if its not already open. It also an happen if we allow the user to switch from one user account to another. The problem never happens if the form is already open or if its still in the cache.
Some of the windows have say 100+ tags mapped this way and only about 10-15% of the the tags are noticably incorrect. I would say that its not just quantity of tags on the form though as it happens on some of the smaller forms. Usually it is the quality that is incorrect but sometimes it is the value as well. When testing with ignition we see usually only the status incorrect but same problem still is present.
As an aside, the presence of debug print statements will sometimes alter behavior.
A button might have code similar to the following which changes the dynamic properties to set the opened window to the appropriate device.
window = fpmi.nav.openWindow(event.source.LinkedWindow)
window.getRootContainer().DataSource = event.source.parent.DataSource
window.getRootContainer().System = event.source.parent.System
A control value might be bound like the following where TagName is a dynamic property on the control. Sometimes datasource and system are combined to a third dynamic property to reduce indirections.
{0}{1}{2}
0 = Root Container.DataSource
1 = Root Container.System
2 = Root Container.Control.TagName
The values usually correct themselves as soon as a new value arrives for the tag (which in our system can be many minutes if the value is not changing). or if the configchanged field is set. Both of these are server side fixes and affect everyone connected but the problem is only with the client so I would prefer not to do anything drastic like “update sqlt_core set configchange = now();” every time a window is opened on a client.
So the initial questions are:
- Is this a known problem? If so, are there workarounds or better approaches?
- Is it possible to cause a control to completely update itself after it thinks its done binding?