Creating templates with OPC tags

I would like to create templates for my vision projects. So far with my templates I have needed to manually import tags from the OPC server into a tag provider in order to read/write with our PLC(Allen Bradley). however, the templates themselves aren’t very efficient if I have to manually drag all the tags I need from the OPC server to the tags.

Is there a more efficient way to interact with the PLC in terms of templates?

That would be Ignition UDTs. If you have regularly repeating data structures in your PLC, you can make a predefined data structure in Ignition to model it, with parameterized addressing. You are not restricted to matching the PLC’s UDTs–Ignition UDTs are independent. When then creating Vision templates (or Perspective views) that will work with the regular structure, you can pass the template the path to the root of the data and let the template indirect bind from there.

You probably want to go through Inductive University (online, free). That would address the basics you are struggling with.

By passing the root of the data, you mean I can pass the OPC path and Ignition will fill the UDT.

I understand the advantage of a UDT but does this help with the issue I am having?

Perhaps we’re confusing your usage of the word “templates”. In Vision, Templates refer to graphical templates that might for example show the symbol and status of a pump. Tag ‘templates’ in Ignition are called Data Types (or UDTs). As Phil said, if you have repeating structures in the PLC, for example a “Motor_VSD_01” UDT or add-on instruction that is used many times, you can and should create a corresponding tag UDT for this in Ignition and then simply instantiate this in your tag browser to create your UDT instances.
Then, in your Templates, you would pass into the Template the tag path to the UDT instance (again, from my reply in your other post, I usually create two template params: deviceParentPath and deviceName, then an internal property called deviceTagPath which combines these together - this makes it easier to both set the parameters at the instance and also lets you easily reference the device’s name without having to do string manipulation on the flul tag path). Then from there, you can then indirectly bind to the tags within the UDT tag instance.

To create the UDT type, you can simply drag an instance of the data structure from the OPC Browser into the Tag Browser, and it’ll ask if you want to create new tags or create a new Data Type.

1 Like

Yes, I am referring to the graphical templates. So it is my understanding that proposition is once a UDT is created rather than having to import each individual member as a tag in ignition, I can just import the whole UDT once.

Am I understanding this correctly

Yes, but it is more flexible than simply importing the type from the PLC. Ignition UDTs can parameterize (model) structures even for PLCs that don’t have data types themselves. And can model data from multiple sources to appear as a unified entity.

Inductive University. Ignition is so much more capable than FT that if you don’t go through IU you will be floundering at every turn.

2 Likes

I understand the concept and will go over the IU relevant to the topic but it doesn’t sound like this helps me import tags more efficiently. I understand the benefit of having a predefined UDT for a template but wouldn’t I still need create a UDT instance and then point each member to the corresponding member, if I am creating a UDT that is not identical as on the PLC? How else would the Ignition UDT know to read tags from seperate tags on the PLC.

No, you don’t have to drag every member every time. Parameterization is the key. IU describes it.

1 Like

I’ll take a look and I’ll see if I have any questions after that, thanks.

Here’s a UDT definition example

Parameters:
image

Tags:

Status tag ‘OPC Item Path’ binding:
image

Note that the item path is bound to the two UDT parameters. This make the tags reference the correct tags in the PLC

2 Likes

I think I’ve got a pretty good idea of what I can do.

My last question would be, is there a way to have variable amount of tags or UDT’s within a UDT. Let me give you an example.

Say I want to create a station UDT but inside each station I have a variable amount of devices, where each device can have its own UDT. Is there a way to create a single Station UDT with a variable amount UDT’s inside?

The help I have gotten so far has been very helpful, thank you all.

No worries.

Re variable tags in UDTs, the answer is no in a technical sense as in you can’t add or remove tags from a udt instance, but you can define all of the devices you’ll need for any station and then simply disable the devices that don’t apply at the instance level. This will effectively override the enabled property at the instance and these tags won’t be subscribed to. You’ll still see them in there but their quality will be Bad_Disabled.
You can override any tag values at the instance for that matter.
If you have groups of stations though that all have the same device configuration, I find it more intuitive to have a udt defined just for those stations. To do this however, you can create a new udt whose parent type is your generic station, and then simply disable the devices you don’t need within your new station UDT definition. It just means that then you can see in the tag browser tree exactly what station type each station is to make it easier in the future for identifying

To pre-empt your next question, in your graphics you can then check to see if a device is enabled by literally reading the device folder’s enabled property:
{Area 1/Sub-area 3/Station A/Big Pump.enabled}

Yea that’s the only way I could think of. Thanks for all your help

Hi,
I have created UDTs by dragging from the tag browser in a previous version of designer (8.0), but the new designer (8.1) is not allowing this action.

I see there is a new tab for UDT Definitions and by creating a new data type I can browse connected devices, but adding a tag structure retains the folder structure.


This is the behavior of the previous version of 8.0. When the motor 1 folder is dragged into the data types folder, there is a pop up that allows the folder structure to be converted to a UDT called "Motor 1". The folder that was part of the "Motor 1" tag folder is removed.


In 8.1, when I add the tag structure from the device browser, the entire folder is nested under the newly created type.

The latest video on IU was created using 8.0 so this issue is not addressed properly. How do I replicate the functionality that was included in 8.0 but seems to be missing from 8.1?

Thanks,
Ali