Parent and children UDTs

Ignition
1

I am having problems doing something that was real easy to do in Wonderware. I badly need to do it here as well and feel like there is surely a way to do so, but I can’t figure it out.

Lets say I have a UDT for a device, with an OPC tag, some memory tags, and a Data Type Parameters in that UDT. The device that this UDT represents can have one to eight sub-devices, for lack of a better name, that are common to the main device and use theData Type Parameter of the main device to make up part of the OPC Item Path for the OPC tags in the sub-devices.

So, I create the main device UDT. We’ll call it Parent for this discussion. Then I create a sub-device UDT, which we’ll call Child. What I want to do is create an instance of the Parent UDT and set the Data Type Parameter to point to its OPC device. Then I want to create instances of any sub-devices of the parent device and link them to that parent device.

I haven’t found a way to do this yet. The instance of the parent device won’t allow me to add an instance of a child device to it, which I kind of understand as that is not part of the UDT it was instanced from. In Wonderware, you would create an instance of the parent, then you could create instances of the child and link them to the parent instance in a hierachical tree fashion such as the following by dragging them and dropping them on the parent.

Parent
_Child01
_Child02
_Child03

If you do that here, the children instances do not appear as children of the parent, on the next level, but instead appear as a UDT instance on the same level as the parent instance, as such.

Parent
Child01
Child02
Child03

The only way I have been able to get this to work is to create a folder called Subs in the Parent UDT, then add one or more Child UDTs in the folder. The problem is that if I add eight Child UDTs to the Parent UDT, which is the maximum it can have, and the instance of the parent I create only has one Child, the other seven Child UDTs are useless and wasting resources. Sure, I can create a Parent UDT that has one Child, another that has two, another that has three, and so on. But that’s bad programming logic.

How would one go about doing this the best way, so that everything is organized and the only Child UDT instances created are being utilized and are linked hierarchically to the parent?

2

Further experimentation shows that I can create a folder in the Parent UDT called Subs, then create an instance of the Parent, then create a couple of instances of the Child in that parent instance’s Sub folder. But, the child instances have Data Type Parameters specific to them and there seems to be no way to access them and set their values. If you double-click the Parent instance, it shows the Subs folder with a + beside it, making you think you can expand that and get to the child instances. But when you click on the +, there is nothing showing in the Subs folder.

If you expand the Subs folder in the browser itself, it shows the child instances and you can expand them and see all the tags in them. But you can’t get to the Data Type Parameters in the browser. Close, but no cigar. Any help would be appreciated.

3

First, I have found that it’s not a good idea to create an instance of a UDT and then add additional tags to that instance, on the fly. When I first started using UDTs I was playing around with that and was getting some weird behavior. Second, Data Type Parameters within a UDT are not accessible outside the UDT, but you can expose their values. To do so you create a memory tag within the UDT and set it’s value to the data type parameter.

I would approach this in one of two ways, which one I’d pick would be based on the number of tags that are involved in your Parent and Child UDTs.

  1. I deal with a lot of tanks, so I created one UDT called Tank that have every possible tag that a tank could have. Not all of the tanks will have all the tags, so what I do is create an instance of the Tank UDT and then set the Enabled to No on those tags that are not used on that instance. This allows me to check the data quality of a tag within the project to determine if this instance of a UDT uses this tag or not. Benefits of doing it this way - I only have one UDT for all my tanks that I have to work with, since all my tanks are of the same UDT type I can pass around the UDT variable as appose to passing around individual tags from my UDT. Drawback - If your UDT has a lot of tags that you would need to disable, that might take a lot of time.

  2. You could create a Parent UDT and a Child UDT and use the regular folders withing SQLTags to set-up your Parent / Child relationships. You would probably use memory tags within the UDTs to expose the UDT’s data type parameters. One of the memory tags that all my UDTs have is called UDTPath and it is a string that corresponds to where the UDT resides within SQLTags hierarchy.

4

Pat, thanks for the help with this. I would definitely not use the first method you described as the child UDT has 51 members. I thought about putting the children in one folder and the parents in another and linking them in some way, similar to what you described. It appears this may be the way I’ll have to do it, unless someone at Inductive has a better solution. Being able to drop a child on a parent as you could in Wonderware would really be nice though. That was a nice feature.

What I’m wanting to do this for is electronic flow meters. Some models only have the ability to measure flow in one meter tube, while others can have up to eight meter tubes installed on them, and all eight are common to the one EFM device. The only difference for each tube is part of the OPC Item Path. For instance, if the EFM is named ABC123, and has two meter tubes hooked up to it, you might read the battery voltage for the device itself with an OPC Item Path of [ABC123]BATTVOLTS. To read the flow through meter tube one, you might use [ABC123]CURRENTMCF/0 where the flow through meter tube two would be [ABC123]CURRENTMCF/1. So the device name of ABC123 is common to all OPC Item Paths. CURRENTMCF defines flow rate and the /0 and /1 define the meter tube for which you want to read the flow rate.

There are also analog inputs, digital inputs, pulse inputs, and other items that are common to the device itself, and can appear in random numbers or not at all. I also wanted to make those children of the parent device as they aslo use the common device name in their OPC Item Paths. And there are other reasons for keeping all of this in a hierarchical format in the SQL Tags browser. One being simple organization. You can look at a device and see all the meter tubes and AI’s, DI’s, etc that are part of it at a glance.

I was really counting on being able to do this in Ignition. I figured if you could do it in Wonderware, you should be able to do it in Ignition also. In general, I like Ignition far more than Wonderware, but I have to give credit to Wonderware for the capability to drag children and drop them on parents and have them automatically linked by a common member.