[00:00] In this lesson we'll talk about UDTs or User-Defined Types. A User-Defined Type is effectively a tag structure. It's an object that contains multiple sub tags sometimes called members. UDTs work under the idea that you have to first create what's called a definition. A definition is effectively the master copy of the User-Defined Type. You then create instances of that definition. Those instances inherit the structure of whatever definition they're derived from. So if you have a definition with a couple of tags each instance will also have a couple of tags. UDTs are best with repetitive structures. Generally speaking, you really only use UDTs when you plan on having multiple instances. You wouldn't create a UDT that you only ever planned on creating a single copy of. But again, the larger paradigm to understand is that when you're talking UDTs, there are definitions and there are instances. Now if we were to look at an example of a UDT definition as well as some instances, we can see here in the designer I'm looking at my tag browser. Inside of any of your tag providers there's this item called data types. Data types is responsible for containing all the definitions that exist inside of this tag provider. You can see I have something called a motor here. The motor has two sub items. It has amps and HOA, and then when we're looking further down inside of my tag provider I have these motor 1, motor 2, motor 3 and their type is actually set to motor, referring to the motor data type up above. These are actually instances of a UDT. If I expand motor 1 here, we can see that it has similar structure. There's an amps and HOA. There's also a parameters area here because your UDTs can utilize additional parameters for indirection. We'll talk about those in later videos. So again the whole point of using these UDTs is to make your life easier later on when you need to start making changes to your tags. So, for example say I needed to add a new tag to these motors. Maybe I wanted a setpoint of some sort for an alarm. Instead of changing the setpoint or adding a new tag to each one of these instances or two multiple folders, I can instead go up to the motor definition here. I can double click on it. We see our structure on the left hand side. I can add a new tag here. So that root item's selected. I can hit the little add tag drop-down. Create a new standard tag. So I'll create a memory tag here. I'll select this new tag. Change the name here. We'll hit enter. You can see that the new tag has been added to the structure. I can click OK. You'll notice that motor 1 and motor 2 got a little bit larger as they now have this new setpoint memory tag. I could also go back to my definition here. Select my alarm setpoint here, and instead of leaving the value blank I could actually type something in here. Hit enter. Click OK. You'll notice they're now all using this new value. Now I just set the default value for this one memory tag here but I can go to each individual instance. So maybe motor 2 should have a different setpoint for whatever reason. I can actually double click here. Change the value. Hit enter. And now this one instance of the memory tag has a different value than this other instance. Now this part's a little contrived. Again, if you have an actual tag inside of your device that's keeping track of this information it would be better to have the UDT pull the information directly from the device. But you kind of get an idea of what you can do. You can create these new members inside of the UDT and then the rest of ignition can use them in useful or interesting ways. Now later on when we start talking about adding history, adding security, adding alarms, again if you're using UDTs you simply need to make a change to the definition and then each instance will get a copy of that change. So, While you don't really need to use UDTs in your projects, when you have repetitive structures like these, they end up saving you a lot of time. As well as just being easier to maintain.