To create a UDT, the OPC path of the members, must be related/organize, in such a way you can add a common parameter to make them work.
But the problem is, when you collect data from a modbus device, the opc path of these tags are Flat.
How does UDT work in real life then? what are the options.
Well I got one idea.
I create a new tag provider.
I create the namespace hierarchy in tag browser:
Now everything in tag browser is nice and organize.
I will set the OPC UA server, to expose all tag providers.
I will set OPC Client to loop back to local OPC UA server.
Now, wala. In Default Tag provider, I can create UDT and add members from the OPC client tag provider.
But this time if I create the instance, its all flat again, on tag browser.
Its like, it worked! but now the table is upside down. Do I need to re-do the default tag provider again to look like a namespace?
Eeewwww! That's seriously ugly.
Some notes about UDTs:
You can do arithmetic with parameters. So if you can arrange your Modbus registers so PLC-side "UDTs" occupy consecutive registers, then a "base address" UDT param on the Ignition side can supply the addresses for the whole block.
You can override specific UDT members' OPC item paths (or other properties) if a particular instance doesn't follow the common pattern. You can even do all of your assignments with overrides, though it somewhat defeats the purpose of UDTs.
If you have several different patterns in your PLC, but they all need to look the same on the Ignition side, there's nothing that says you can make multiple UDT definitions, each with the same members but different parameter setups. This generally precludes using UDT properties in your pages/views/windows/templates, but there are multiple reasons to avoid those. (Use indirect binding with tag paths.)
When working with register addresses and arithmetic, it is typical to not use Modbus address mappings. My alternate Modbus driver doesn't use mappings at all (it exposes the regular names as browsable).
Thank you. I noted this..