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.
Learn how to manually configure properties on a UDT instance when the instance needs to differ from the UDT's specifications.
Video recorded using: Ignition 8.1
Transcript(open in window)
[00:00] When configuring UDTs and UDT instances, we can control all of the important properties of our UDT instances using UDT parameters. However, sometimes it might be necessary to manually change tag properties for a specific UDT instance. Maybe we want to change alarm set points for a specific device, or maybe we want to add in some custom scaling options to correct for a device discrepancy. Whatever the reason, it's easy in ignition to make localized changes to specific UDT instances. To demonstrate, I have a sensor UDT instance here. We created an Explorer, this UDT in previous videos, but I've added a tag for this example. So our UDT is now showing humidity, temperature, and pressure tags for a given sensor. And it's using the SensorNum parameter to decide which one to show data for. So for instance, if I expand this pressure tag in sensor one, we see that it's tied to sensor one's pressure item on our simulator. Now this is working just fine.
[01:02] If I expand the sensor to instance right below it, we can see that our tags are looking good in sensor two as well. But if I expand sensor three, we'll note that we're not getting that pressure tag coming through correctly. To see why this is the case, I'm going to click the plus icon at the top here, and select browse devices. Just so we can see what our OPC structure looks like. I'm going to dive into devices, dairySIM, overview, and then find my sensors a little ways down here. And if I expand my instances, we'll see that sensor one and sensor two have pressure tags called pressure, and sensor three's tag is just called press. Since the UDT is set up to use an OPC item called pressure, it's not going to find this press item on sensor three. So we'll have to find a way to correct it. Now, maybe a simple inconsistency like this, is something we could and should fix on our PLC. But it's easy for us to handle this in ignition as well. And the technique we're about to see could be used for many other data or structural inconsistencies too. To correct our problem here, I'm going to find the sensor three instance in my tag browser, and double click to pull up the configuration for the tag.
[02:08] In here, I'll select the pressure tag, and we'll notice that each property in the tag editor, has a small gray circle next to it. This gray circle indicates that the value on the property is coming from the UDT definition, and parameters on this instance. But that said, this interface gives me the ability to change that. I can change any properties I'd like, but the one I need to change, is the OPC item path. So to do that, I'm going to find that property, click the chain link icon on the right hand side, and then select to edit, which will let me change. The reference has been configured on the property already. So in here, we're building an OPC item path from the sensor numb parameter. And all I need to do is change this final item here. So I'll find pressure, and change it to just press. And then I'm going to hit commit. So it's important to note here that what I've done is make a change to this specific instance. Just as sensor three instance, living in the sensors folder. None of the other sensors is affected, and the UDT definition has not been changed.
[03:05] We'll see here that the gray circle next to the OPC item path has turned green, indicating that the property has been overridden for this instance. So now we can test out our changes, by hitting okay, here. And when we do, we'll see that the correct value has come through on the pressure tag. So you know our override worked. We'll also see a small half-filled circle icon, appear next to the tag. Indicating that the tag property has been overridden. And with that, I'd like to talk about one very important consideration in this process. Since we've made this change to sensor three, the UDT definitions value for that OPC item path property, is going to be ignored on that instance. Which includes any changes that might be made in the future. In other words, that OPC item path property on the pressure tag, in the sensor three instance, can only be changed directly by hand on that instance. It cannot be changed by modifying the UDT definition. However, if we wanted to revert this, that's a relatively simple process. We just go back into the tag editor for our pressure tag.
[04:03] And if we click on the green circle, that we'll remove our override and set the property value back to the one controlled by the UDT definition. So that's all it takes to make changes to a specific UDT instance. Overriding UDT instances is a great approach, when there's a one-off problem with a specific UDT instance, when you want to create a test case, or when a specific instance just needs a slight tweak. In later videos, we'll look at some more complex ways of working with UDTs, including a way of overriding or modifying a UDT, that is more globally manageable.