Hi,
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.
Thank you.
Well I got one idea.
I create a new tag provider.
I create the namespace hierarchy in tag browser:
Site1/Area1/Line1/speed
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..
Agree
Super late to this party, but what about setting up UDTs to use referenced tags?
Totally different from Modbus, as tags use hierarchical names, not ranges of addresses. It would be more like using UDTs of OPC tags from PLCs that use hierarchical names (Logix). Then it is really the same, just with base tag reference parameter instead of a base item path parameter.
I'm not sure what you are saying. I meant use base tags that have the OPC path that includes the modbus address. Then the UDT uses reference tags to point to those base tags. Then you can use the name of the tags with parameters to choose the tags/folder you want to reference.
Then whatever the modbus address is, the UDT never sees nor cares about since it is only using the names of the OPC tags.
I don't see any reason you would use reference tags for such a case. Please describe your use-case, perhaps with an example.
The primary purpose of Ignition UDTs is to make it easy to create tags of a certain pattern, with parameterization of start addresses for blocks of related tags.
My current project I have a list of tags pointing to a modbus connection. There are multiple copies of machines stored in folders titled something similar to "machine1, machine2,... Etc" In this PLC however whoever set up the addressing did not stick to a consistent convention for the addressing. So arithmetic can't be used to edit the tag path of a UDT. I am unable to make changes to the PLC.
What I did was create a single UDT to use on something like a details page for each machine. This UDT has all tags each folder has but referenced instead of OPC. The tag path then takes a parameter for the folder of whicher machine I want the UDT to reference.
I can post photos tonight if you need more clarification. If you have a better cleaner idea then I'm all ears too!! Lol
I would leave the OPC tags in the machine UDT. Parameterize where you can, and use Item Path overrides where you cannot. If there are multiple patterns, make multiple UDTs, but with consistent member names. Then any of the UDTs can be used in the UI based on tagpaths and indirect binding.
If there is no patterns anywhere, just use folders of tags without any UDT. Use the same tag names in each folder, so you have common names to use with tagpath-based indirect binding. I would not use any reference tags for your case. It is just added complexity.