You can help by commenting or suggesting your edit directly into the transcript. We'll review any changes before posting them. All comments are completely anonymous. For any comments that need a reply, consider emailing firstname.lastname@example.org.
We are experiencing playback issues from our video hosting provider. Please check back shortly.
7:21Creating UDT Definitions
3:07Manually Creating UDT Instances
3:55UDT Multi-Instance Wizard
Take topic challenge
Learn how to create and configure UDTs in Ignition.
Video recorded using: Ignition 8.0
Transcript(open in window)
[00:00] In this lesson we'll talk about creating UDT definitions. UDT definitions reside under this item called data types, data types exist inside of a tag provider. So you'll create your definitions inside of this data type. To do so you simply select data types, and then hit the add tab drop down, at the top of the tag browser. And we can create a new data type from here or of course we can create folders if we plan on having a lot of UDTs. We can start implementing folders now to help with organization later. But, I'll stick with the root here. I'm going to create a new data type. You'll see the tag editor appears. On the left hand side is this type structure area where we effectively show you what the structure of the UDT is in a tree format. So I have the root of my type selected here. We can change the name under the name property. There's also an add tag button here, which I can click on the drop down and then start adding other types of tags. So I could add in an OPC tag here, which now exists under the tree, I could then start changing the properties on this one tag. Now building a UDT definition like this, is absolutely one way to go, but the fastest way to create a UDT is by dragging and dropping from the OPC browser. So, I'm going to cancel out of this here, and we'll lose the changes, that's fine. Instead I'm going to head over to my tag browser. I'm going to open up OPC browser. Now if you're connecting to devices that support browsing, we can actually find any browsable items here, and then drag them into the data types folder. So if I drill down into Ignition OPC-UA Server or really any of your UA servers. I'll go down to devices, this connection's using the Dairy Simulator driver. I'll expand this, I'll go down to the overview folder, and I have a bunch of motors here. You'll notice that all of the motors have a similar structure. This sort of repetitive structure is ideal for UDTs. So I'll grab motor one here, the entire folder motor one, and I'll drag this into the data types folder inside of the tag browser. And when I drop the folder here, it gives me a little pop-up asking me to confirm. Again, data types is special, it wants us to confirm that we want to create a new UDT, so we'll create a new type. And you may notice now, that if you look at data types, you can expand this. And you'll see that motor one exists as a definition, I can expand this, and then I can see the two tags under it. So again, we just took the structure from the OPC browser and we recreated it as a UDT inside of my tag provider. Now we don't see any values here, that's because UDT definitions don't hold, they're not actively executing. Now when you're creating your UDTs like this, you want to very much generalize them as much as you can. I don't want to call this definition motor one, that's somewhat misleading, although currently it is only pulling values from motor one. Although later on when I start creating instances, I'll want this motor finished to represent motor five, motor six, really any of my motors at any given point. So to accommodate this, let's make some slight changes. I'm going to double click on my motor one definition. You'll notice that the tag editor is open, and again with the root item of the structure selected I'm going to change the name here. So this is just going to be a motor, I'll just get rid of the one in the space and I'll hit enter, you'll notice that when I hit enter it does actually commit the name change. Now something else you'll want to be aware of, if I select the Amps tag here, this is an OPC tag, we've seen OPC tags before so we know that the OPC item path is were this tag is deriving its value. If we look in the path here, if I were to resize this little bit, you'll notice that the path is coming from motor one. So it's actually hard coded to a specific folder inside of this device connection. So, right now any instances of this motor definition I create, we'll all be looking at motor one, so when your using UDTs it's fairly common to also utilize a parameter. So if we head back up to the root of this type, so if I click on motor there's this parameters property, now this is special, each member, each sub-tag inside of the UDT can reference these parameters fairly easy. So, I'm going to create a motor number parameter here, that then my Amps and HOA tags will start to utilize. So for parameters here, I'll hit the edit button on the right, you'll see a big table here, I'll add a row by clicking on the plus button on the right. And we can change the name of the parameter by double clicking under the name column and typing something in. So I'll type in motor number and hit enter to commit the name. Now I did use underscore here, you can use spaces I just happen to use underscores. Now the value over here is actually the initial value for this parameter. So when we start creating instances, we can pre populate them. So when we start creating instances, we can pre populate those instances with a particular value for each parameter. I'm going to leave this blank for right now, because I can also override this parameter value later on, so when I create motor five I can give a motor number to that instance of five. So we'll commit this for right now. I'll head over to my Amps tag here. Let's go down to the OPC items path again, now instead of just typing into here though, let's use a binding. I'll hit the little binding button on the right. Now there is a parameter area here, which allows you to access that motor number we just created, as well as a bunch of built in parameters. Now I actually don't want to use this here because this would replace the value of this entire property with my parameter. What I actually want to do is I want to edit this binding and I don't want to replace the entire path, rather I want to replace part of that path. So if I get rid of this little one here, I can delete that and then with my text cursor right where the number used to be I can hit the little icon on the right hand side, you can see from the pop-up. This allows me to grab parameters or UDT parameters that exist within this UDT. so I'll click on this, this shows us motor number again when I select something from over here. It does populate into the path, we can commit this. Now ideally I'd like to do the same thing with the HOA, which I won't bore you with you get the idea, it'll be exactly the same process. Now taking a step back and just looking at these parameters, the parameters can be really utilized almost anywhere inside of one of these sub tags. For example, I could actually have the name of the device, so inside of the square brackets that could actually be a parameter. The entire OPC item path can be the parameter, the data type, the value source, all these other properties can also utilize these in some interesting ways. So when you start using these UDTs, the real power of them is in how they use these parameters.