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 manually configure properties on a UDT instance, when the instance needs to differ from the UDT's specifications.
Video recorded using: Ignition 8.0
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 we want to add in some custom scaling options to correct for some discrepancy. Whatever the reason, it's easy in Ignition to make localized changes to specific UDT instances. So to demonstrate, I have a UDT here called Turbine. Now the way I have set up this UDT is that each instance takes a parameter called TurbineNum, and it's passing that number into the OPC item paths of its tags. So for instance if I expand this Power tag in Turbine One, we could see that it's tied to the Ramp1 OPC item on our simulator. Now this is working just fine, If I expand the RPM tag right below it, we can see that this is just tied to RandomInteger1 and then if I scroll down a bit in the tag browser, if I expand the RPM tag for Turbine Two, we can see that it's RandomInteger2, which makes sense because we are just passing in that two as a parameter to the UDT Instance. But there is one problem if we scroll down a bit more. We can see when we pass a three into Turbine Three, we get an error on our RPM tag. This is because the RandomInteger3 tag doesn't actually exist on my device. So to rectify this, I'd like to point the RPM tag at a different OPC item, but only for Turbine Three. To do this, I'm going to right-click on the RPM tag, and I'm going to select Edit tag. And this will bring up the tag editor specifically for the Turbine Three UDT instance. We can see it already has the RPM tag selected, and we'll notice as well that each property in the tag editor has a small gray circle next to it. This indicates that we have not overridden the property, that it's using the specifications laid out by the UDT and the parameters provided to this instance. But from here I can change that. Notice 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 click the little icon on the right, and I'm going to chose browse OPC, and then I'm going to find the tag that I'd like to use. So I'm going to go into devices, generic simulator, and again this is just a demonstration. In general, you'd probably know which tag you wanted to use. But I'm just going to pick a Sine tag, so let's say Sine Three, and then I'm going to commit. And now its a bit hard to see, but the OPC item path has changed. We can see its now pointing to that Sine tag. And if I revert out of this, the gray circle next to the OPC item path has turned green, indicating that the property has been overridden for this UDT instance. The change we just made will not effect any other UDT instances, only the Turbine Three instance. So let's click OK to see if it works, and yep, we can now see that we're getting a value through to our RPM tag. And now I'd like to talk about one very important consideration in this process. Since we've made this change to Turbine Three, any changes on the UDT definition related to that OPC item path will not propagate through to Turbine Three. In other words, this OPC item path property on the RPM tag in the Turbine Three instance can only be changed directly, it cannot be changed by modifying the UDT definition. However if we want to change it back, that's a relatively simple process. We'll just go back into the Tag Editor for our RPM tag, and we'll click on the green circle. Now having done that, if I check out the item path again, we can see that it's been changed back to the original specifications. So I'll just revert out of this. And if I hit OK, we can see that the tag has gone back to being an error. So that's all it takes to make changes to a specific UDT instance. While flexibility is best built into UDTs by virtual parameters, occasionally it could be quite useful to make manual changes.