As we've discussed already, UDTs are custom complex types we can use to represent repeated text structures in a way that allows them to be organized and maintainable. In this lesson, we'll focus on how we can create and configure these types which effectively means we'll be working with UDT definitions in this video. To create a new UDT definition, I'll find my tag browser here on the left-hand side and select the UDT Definitions tab. Once I have that tab selected, I can right-click within the main tag browser and select New Tag, New Data Type, or I can click the plus icon in the top left and select New Data Type from there directly. We can also create folders if we want to organize our UDTs a bit more. Selecting New Data Type will pull up this UDT definition editor, which comes in two parts. On the left-hand side, we have our type structure which allows us to declare member tags for our UDT. On the right-hand side, we'll see properties for any node we've selected on the left.
So right now we have our type itself selected on the left. So, to get us started, let's go ahead and create a name for our new type. How about we call it Sensor? And then, for our sensor type, we have some other options which we'll cover a bit later. But one thing I can do now is give my type a color, which will make it easy to distinguish my UDT instances inside by tag browser. So, how about I expand my color dropdown and select a nice shade of blue? It's worth noting that you can also bind this color and make it dynamic using the chain link icon here. Now that we have our UDT properties sorted out, I'm ready to add some member tags. So to do that, I just need to find this panel to the right of the type structure. I can use this panel to add folders, tags, or even nested UDT instances into my structure here. The element is just added immediately below the current selection in my type structured dialogue. So, since I have the root node selected here, if I wanted to add a tag to my UDT, I could just click the tag plus icon here, select the tag type and get rolling.
Certainly, that's what I'd want to do if I was working with a memory, expression or query tag in here. However, I happen to know that I'm going to be working with OPC tags for my sensor because my UDT is intended to model an actual device. With that in mind, I can actually select the fourth icon here which allows me to browse my connected devices. Naturally, this option will only be useful if your device supports browsing or for something like Modbus provided you've set up your address mappings yourself. Inside of here, I'll expand Ignition OPC UA Server, Devices, DairySim, Overview, and then scroll down until I find my three sensors. If I expand those sensors, we'll find that they contain the same humidity and temperature tags, which makes this a perfect time to use UDTs. In this case, I just want my definition to model a single sensor. And then, ultimately, I can create a UDT instance for each of my three sensors. So, to model just one sensor, I'll find Sensor 1 here, click on Humidity, then hold Ctrl, and Ctrl + click on Temperature, which will do a multi-select.
And then I'll click Add at the bottom. And that'll add two OPC tags into my structure. Now, it might seem like I'm done here because I have the exact tags that the sensor OPC structure calls for. However, there is one small problem. If I select the humidity tag here, which again is an OPC tag, and I find the OPC item path property on the tag, If I make that wide enough we'll see that the item path is set to Sensor 1. This makes perfect sense. It's the OPC item we selected in our picker a moment ago. However, our sensor data type isn't supposed to work for just Sensor 1. We want it to work against any of the sensors. So, in a way, this OPC item path can't be the same on every UDT instance. It's going to need to change in some way. Thankfully, UDTs can handle this innately, all we need to do is configure a UDT parameter which will be set whenever we make an instance of this type that can control what sensor we look at on the device. To do this, I'm going to click the root node of my type structure, and find the parameters field on the right.
On here, I'll click the pencil icon, and then click the plus icon to add a new UDT parameter. Now, we have a few different options for what parameter to use. We could ask for a sensor's name or an OPC item path to the sensor, but let's keep things simple and call our parameter, SensorNum. So we'll expect a parameter that's something like one, two or three that we can use to make our OPC tags work. Now, we have another couple of fields here, our data type is defined as integer, but other options are floating point and string. And then we have a value field. It might be tempting to put something in the value field, but remember, we're on the UDT definition here, and we're meant to decide which sensor to look at when we actually create instances. So it's fine to actually just leave that field blank on here. And with that, I'll click Commit. We're almost done. We just need to go modify our humidity and temperature tags to use our new parameter. So, I'll select Humidity here on the type structure, and then find that OPC item path field.
Now, on this field, I just want to change a single character. I want that one here to be replaced with the parameter reference. To do this, I can click the chain link icon on the right-hand side. And then, from there, I have a few options. Browse OPC will allow us to pick a new path. Parameter is probably tempting, but it'll replace the entire field with the parameter. Remember, I just want one character changed. So, I'll actually be clicking Edit here. And now we're given the full OPC item path and a curly brace icon on the right-hand side for adding parameters into the path. All I need to do is find that one in there, delete it, and then without changing my text editor position, I'll click the curly braces and then find my parameter, so, SensorNum. That's all we need to do to move on here, but it's worth noting that any part of the OPC item path can be made dynamic, including the device name in the square brackets, or the item names themselves, or even the entire item path.
That's it. Our approach is good as is, so if I hit Commit, I just need to do the exact same thing on the Temperature tag. I'll select the tag, find the OPC item path, click the chain link icon, Edit, find the one and delete it out, then use the curly braces to bring in SensorNum, and then finally hit Commit. And now our UDT is all set up and ready to deploy across our tag structure.