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 email@example.com.
We are experiencing playback issues from our video hosting provider. Please check back shortly.
Learn how to configure UDT inheritance and create parent and child UDTs.
Video recorded using: Ignition 8.1
Transcript(open in window)
[00:00] One novel way of varying the structure of a UDT, to more closely match the specifics of your setup, is to use UDT inheritance. UDT inheritance is a feature available when designing UDTs, that allows us to base the starting structure of one UDT, off of another UDT definition. If we have several changes, we want to make to some but not all instances of a UDT, inheritance can be a great way to implement those changes in an organized way, without using UDT overrides on instances directly, which can be difficult to manage at scale. To demonstrate, I've got a sensor UDT instance here, and it's working just as expected, giving me back humidity and temperature tags. I'd like to create a new kind of sensor UDT, based off of this UDT, then incorporates some additional features. So to create our new UDT, I'm going to navigate to my UDT definitions tab, click the plus icon at the top, and select new data type. And the name of my new data type is going to be, fancy sensor.
[01:06] In effect, what I'd like to do for this UDT is start from the sensor UDT, but then incorporate a pressure tag for my PLC. So we're imagining here that we have some simple sensors that keep track of humidity and temperature, and then some fancier sensors that also include a pressure tag. So in order to configure inheritance here, I'm going to find the parent data type property, expand the dropdown, and select my sensor data type. Once we do that, we see that our fancy sensor UDT, is inheriting from the sensor UDT. What that's going to do is pull through the entire configuration of the sensor UDT, into this UDT. Although in order to see it, we'll need to click the refresh button in the top right. And now we'll see that our humidity and temperature tags appear on the left. However, we've done a bit more than just copy one UDT definition onto another. This UDT is now built on top of that existing type. And if the sensor UDT is ever changed, those changes will be reflected on the humidity and temperature tags here.
[02:05] Now that we have that setup, we can configure tag property overrides, introduce new tags or alarms or history, change UDT properties, and so on. In my case, what I'd like to do, is just add an additional tag to show pressure. And I'll be doing it in the same way we did when we first created the sensor type in previous lessons. So I'm going to select the route of my UDT structure, then find and click the browse devices icon on the right, drill into my OPC UA server, find devices, dairySIM, overview, then scroll down and find my sensors. Expand sensor one and select the pressure tag, then hit, add. And with that done, I just need to configure the item path correctly. So I've pulled through the pressure tag from sensor one, but I need to modify the final path to use my sensor numb parameter, instead of just being for sensor one. So I'm going to click the icon next to OPC item path, and click edit.
[03:05] Then I'll find the one in here, delete it, and replace it with a parameter reference to sensor numb. And that's all it takes to configure the pressure tag I'd like to use. So I'll click commit and then click okay. So let's conclude by creating an instance of our new data type. I'm going to navigate to my tags tab, and then click the plus icon at the top, select data type instance, and then fancy sensor. Once the tech editor comes up, I'll name my new instance, fancy sensor one, and then all we need to do, is configure the sensor numb parameter. It's worth noting that we never specified this parameter on the fancy sensor UDT. It came directly from the parent UDT. So let's set a sensor numb of one and then click commit, and click okay. And now if we expand our new UDT instance in the tag browser, we can see that all three tags are working as expected. On a final note, there is one more neat feature behind UDT inheritance. If I ever configure a custom property in vision or perspective that requires our sensor UDT type, I can pass to that property a fancy sensor type and it will work just as well.
[04:11] So in addition to helping with organizing and maintaining UDT structures in my tag browser, UDT inheritance can also make project development simpler, in both vision and perspective.