Is there a reason why using one parameter with the whole OPC path (minus the member designation, ".Status.HMI") is any different that separating the PLC name and PLC tag name and building the OPC path. You're appending the ".Status.HMI" or whatever else in the member definition anyways. Below is how currently have it.
To be clear, this is referring to both a view's parameters as well as its custom properties? If this is the case, then I guess my understanding is that I should never really define anything as an Ignition UDT type anywhere other than in the tag explorer when creating a tag? Ignition UDTs and custom properties on things seem like super convenient development features, but this seems to take away most of that convenience, but I guess if performance suffers otherwise, there's nothing you can do.
I've read through that and a lot of your other posts on the matter, though a lot of it does go over my head a bit. First, I'm not referencing any AOI-defined UDTs from the PLC. Everything is a separate device-specific UDT used by each AOI, so I should be good there. It seems like I need to keep everything at the same tag rate if they're in the same UDT as the slower tags(which they are). If I need faster response from my buttons, I'll look into separating the User control buttons and statuses into their own separate UDT used by my AOIs in the PLC. To be clear in this topic, if any part of a PLC tag is accessed by the OPC UA server, it pulls the entire UDT tag (the entire highest level base tag), right? It doesn't ever just get the tag data from members of a tag (even if the members themselves are nested UDTs)?
It seems like my fixes are fairly straightforward, but will require some redevelopment and will make ignition not quite as easy to develop (since now I'll have a lot more basic properties and indirect tag bindings). Please let me know if I'm missing something. I appreciate all your help!