I've found myself making a lot of templates where I have a tagPath parameter, and from there I make a few custom properties that are indirect bindings on this tagPath plus other properties. Things like .EngHigh, .EngLow, .FormatString, etc.
I do it this way, because just binding to the tag path itself gives you the value specifically. Instead of making multiple bindings for a custom property, I was thinking it would be nice if I could just make one custom property object and bind that to the "tag" as in the qualified value of the tag. That way it would just bring in all those other properties with it on that single binding.
Is this possible? Or would it be a good idea if it was? Would I save anything performance-wise or should I just continue making individual custom properties and making indirect bindings to different elements in the tag?
Qualified values do not have those other properties, just .value, .timestamp, and .quality.
You may find my Integration Toolkit's tags() expression function helpful for cases like this. (It does not suffer the same problems as the native tag() function, but does deliver nulls on first execution.)
2 Likes
As Phil mentioned, your use of "qualified value" is either confusion on your part about what a qualified value is, or an overloading of a common Ignition term with a very specific meaning.
Within Ignition, a qualified value is just that - any type of "value", plus some qualification - specifically, a quality code and a timestamp. So every read of any subproperty of a tag delivers one qualified value; there's no way to "extend" a qualified value with extra qualifiers.
That said, it is technically possible (though probably inadvisable) to do effectively what you want. Every tag has an invisible jsonValues property node; if you bind to SomeTagPath.jsonValues, you get a qualified value that contains, as its value, a rich JSON "document" containing the sub-properties of that tag. However, that means, whenever your binding re-evaluates, you're asking the gateway to redeliver all of those values. It's less of a performance footgun than the similar concept in Vision (UDT types + bindings) for a couple reasons, but generally I adhere to the principle that you should only bring in the information you actually need.
5 Likes
Yes, I mistook what a qualified value was. I meant the subproperties of a tag like you're saying.
At any rate, that's what I was wondering. Sounds like having a single binding calling up all of a tag's subproperties would usually cost more overhead than having multiple bindings for specific things.
1 Like