Got a weird one. I have two Ignition gateways for a single customer at two of their sites and I would normally reference UDT Instance parameters using slash syntax rather than a dot since then it's adaptable to non-udt structures as well.
E.g. instead of referencing:
Area/Motor 1/Parameters.Parameter1
I normally use:
Area/Motor 1/Parameters/Parameter1
This has worked for every other site I've worked on, but i'm having issues on just one of these 2 gateways where the value being returned doesn't correspond to the parameter's value.
For example, the value returned when I read "../Parameters/Parameter1" is 2, but the parameter value is actually 101.
If I read "../Parameters.Parameter1" this reads 101 correctly
This has actually caused us some data corruption, since we're using some of these values as primary keys, and the reads of parameters using a "/" that resulted in reading invalid values (e.g. 2 instead of 100) resulted in they wrong primary keys being used for SQL tables... I'm yet to discover how much this has corrupted our data
Is this reproducible if you take a .gwbk from one of these sites and restore it somewhere else? If so, if you can send that in to support so we can get it in front of a dev system where we can breakpoint and figure out exactly how this is getting mixed up, we can get to the bottom of it.
So the issue here is while a / works, it doesn't subscribe to changes of parameter value. I believe this was left in to support the same behavior as we had in 7.9. What has happened is the parameter value has changed since the UDT instance was initialized and the / reads haven't updated the value where the . tags (because they have a subscription) do update. If the tag were to be restarted, it would sync up again until the Parameter value is modified during run-time at which point it will be different. If the parameter value will be changing for the UDT instances, I would recommend using the . formatting.
While I will write up a ticket regarding this, I am letting you know there we be a lot of debate about changing the existing behavior as there isn't an in-significant amount of risk to existing implementations of Ignition.
In troubleshooting this, I am seeing a secondary issue that we likely will fix where mixing . notation and / notation causes the parameter value to not be represented correctly in Tag Browser or in the . tags. I would double check that none of your implementations are setup in a manner where both are used in a single UDT Def/Instance.
This part is a bit confusing. If someone is binding to a parameter value of a UDT instance, wouldn't they be expecting it to be reading the value that it is, not that value that it first was?
I was binding to ../Parameters/Param1 within the GUI (perspective/vision pages), so do you mean if I was mixing these with bindings as well to ../Parameters.Param1 that it could cause an issue representing the value in the tag browser?
We have a couple of different areas in the app where the behavior for tags is slightly different based on somewhat niche needs. For example, Tag script events have a similar paradigm. We have the Modern and Legacy approaches which are similar in nature.
The behavior of tag() and {...} notation in expression also have slight nuances to them as well (see the note in the tag() description)
This only looks to be an issue when mixing syntax within a UDT definition. There is something happening to cause the parameter not be evaluated properly when it is first set.
The attachment below will import tags that show the issue. If you modify the value in [provider]All/Parameters.Parameter1, you will see the parameter revert back to the original value (along with both . notation tags, but not the / tags). If you restart the tag, the the new value you set is shown as expected. Whatever is happening needs more investigation, but the behavior is clearly wrong. ParameterTags.json (6.9 KB)