We pass a TagGroup/ScanClass parameter into most of our UDT’s, then bind that to the TagGroup property of all the Tags in the UDT, the value is usually set on the UDT definition(it is not normally set at instance level), when we change the value of this parameter at the definition level, it get passed down to the instance parameters OK, but not to the tag properties inside of the UDT, see below.
Restarting the tag or tag provider will resolve the issue, but for large number of tags on live system this is not practical.
This may have been fixed somewhere in 8.0.3 or 8.0.4, as I cannot reproduce the same behavior in a 8.0.4 nightly build. Whenever I update the parameter in the UDT definition, the tag group property in the OPC tag in the UDT instance updates at the same time. If you can, could you try to download a 8.0.4 nightly build and test it with your UDTs?
I have tested this again with the latest 8.0.4, and issue still exist, it only seems to affect OPC tags, in my test project I have two tags one expression tag data type string and one OPC tag data type integer, the expression tag works as expected.
I have attached a complete Tag&TagGroup export from my test project(gateway backup was too large), you will need the dairy simulator to satisfy the OPC tag or redirect it to something else, if you then flip the UDT definition parameter TagGroup between DemoGroup1 and DemoGroup2 and refresh the tag browser, you should see the TagGroup of the OPC tag get left behind
OK, I was able to reproduce with your example tags and I filed a ticket. In the meantime, here’s an experiment to try: rename the UDT parameter from ‘TagGroup’ to something like ‘MyTagGroup’ and see if the behavior persists. When I tried this with your tags, the UDT parameter update took effect without issues. I am thinking that there may be some interference if a udt parameter has the same name as an existing tag property.
It turns out there was a bug that was incorrectly equating the parameter “TagGroup” with the tag property of the same name, and squashing the change notification, thinking that the tag had overridden that value locally.
Currently in tags there shouldn’t be any overlap between parameters and tag properties, because we don’t allow binding to tag props (except in expressions). However, from a conceptual/code point of view, they are very similar, and if we decide to allow prop binding in the future, it will look up the name in Parameters first, and then the tag second. In the case of expressions, we somewhat allow this, as the syntax “this.tagGroup” should get you the tag group of the current tag, OR the parameter value, if such a parameter was defined. There was a small issue with how this was working with default property values, that will also be addressed in this ticket.
I would prefer the reverse, and some indication of or barrier to using parameter names matching tag properties. Possibly a barrier for the standard property names and indication for any tag properties defined elsewhere. Principle of least surprise...
