UDT Design question - negative effects of Unconnected tags?

I have an idea for a UDT that will take several OPC tag connections, in combination with a couple of parameters that will enable me to create UDT’s for nearly everything in my entire project. The catch - in many cases, not all the tags that I’m declaring in my UDT will have a corresponding connection when I create the data tag(s) from the UDT. In that instance, I’ve already come up with a way to use an expression to “shunt” the OPC tag status over to an expression tag that can create a “workaround” in the event that the source OPC tag in question doesn’t connect to anything (because there won’t be anything in that instance to connect to) and returns “null” so that I can use the expression tag for things like History and Alerts trigger(s).

so my question is - what kind of negative effects will this practice have if approximately 1/2 to 2/3 of the data tags I plan to create using this method end up with at least one or possibly up to 2 (so far) OPC tags, and hence the corresponding expression tag as well (so for each one null OPC tag, 2 tags will end up labeled with that green circle with a question mark icon in the SQLTags browser), have no “real world” connection when the data tags are created? Will this condition cause problems for the system if there are ~900-1000 instances of such data tags?

I doubt there will be much of an issue. I’m not sure I quite understand how the multiple tags play together, so perhaps you could post a CSV export of an example setup just to clarify, but fundamentally an opc tag with an invalid path doesn’t really put much strain on the system. The opc client subscribes against the server, the server says “hey, I don’t know about that, here’s a ‘bad quality’ code”, and that’s about it.

Beyond that, 1000-3000 tags isn’t really much (although in this case I guess you’re just talking about this type of tag), so I doubt you’d run into any other performance problems either.

Regards,

Awesome! You answered my questions and concerns perfectly, and that’s what I was hoping to hear. This block that I’m looking to create will serve as a foundation for other UDT’s that will inherit from it as well as becoming a functional UDT itself in the sense that it will be used to monitor the states of 100’s of pieces of equipment on it’s own as well as part of the foundation for other UDT’s.

I’ve attached a .csv as you requested. Please let me know if you see anything that sends up a red flag. Thanks!
UDT-MTR_VFD.csv (5.44 KB)

Hi,

I think you’re more or less on the right track. However, I think that with the way you currently have it set up, bad quality in the opc tag will propagate up through the expression (expressions acquire the worst quality of referenced items). Instead, I would check the quality code. Good is always 192. So, like this:

if({[.]F_BK.Quality} = 192,{[.]F_BK},0)

Hope this helps,