LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Duplicate control labels found when enumerating controls?

Hello everyone, hopefully someone can help me with this frustrating problem.

I've got a short bit of code that runs at the start of one of my VIs that gathers up all the control/indicator reference IDs and their Label.Text properties.  The interesting thing is that for a few of the controls, I see a duplicate Label.Text but different reference IDs.  I've already done a search in the front panel for the object and I can only find one instance of the object with that name.  Any ideas why LV might be finding two instead of one?

It happens for specific objects, not all of them, and it is repeatable.  I've attached the small subVIs that cycles through all the control reference numbers (LV 6.0).  Since there are Tab controls on my main VI, I do ensure that I select the various pages and grab the controls from inisde as well as the main controls.  It's just very confusing to see that there might exist two controls with the same label even though that shouldn't be possible.  The first VI enumerates all the controls and provides an array of reference IDs (it also has a search function when filling the array if desired but I don't use it right now so it returns all the controls).  The second VI is supposed to build up clusters that are related to each other.  My controls all have one digit in their labels that identify their relationship to each other (for example, all controls and indicators with a "2" in their label belong to the second group such as "Volts 2", "Amps 2", "Watts 2", "Temp 2", etc.) so this second VI just cycles through all the IDs found and gathers them together by those clustering identifiers.  This is the point in which I see a few controls show up with exactly the same label text but different VI control reference numbers.  It makes no sense.  I dont think the problem is in the second VI that builds the cluster since it's only iterating over all the controls provided by the first VI.  But I can't see how the first VI even manages to come up with two controls.

Thanks,

Alex

Message Edited by AlexCarver on 03-21-2007 03:12 PM

Download All
0 Kudos
Message 1 of 9
(3,773 Views)

Hello Alex,

Could you please post a simplified example with instruction on how to run it?  I ran your code and I didn't see anything immediately apparent to me that was wrong.

Regards,
Justin D

0 Kudos
Message 2 of 9
(3,741 Views)
I'm not sure if I can make the subVI any simpler but I'll attach an updated file which has an array of string indicator that lists all the names inside the front panel of the subVI as obtained from each control's Label.Text property.  But to use it, create a new VI and populate it with many controls, many of them sitting inside tab controls.  Now in the wiring diagram for the VI, drop the subVI enumeratecontrols.vi and wire into it a reference to its parent VI using the Open VI Reference.  What you'll see if you open the subVI's front panel and execute the parent VI is the Label.Text values for all the controls in the parent (minus tab controls).  In my case, there are over 400 controls in my main VI but I see some duplicates when I execute this subVI to get all of their references.

If this isn't quite clear, let me know and I'll try again and try to do some screen grabs.
0 Kudos
Message 3 of 9
(3,732 Views)

I ran your example in 8.2 and it works like expected.  I have multiple controls, some with the same name and some with different names.

Your VI found all the controls and got the correct names, including the same named controls.

Is the issue you are seeing that some controls have the same name, because that is completely legal, so you may get different references?  One way to find the controls that you may think shouldn't be named the same is to modify your VI to tell you when a duplicate is found, and then set the blinking property of the controls.  That may allow you to go see which 2 are blinking therefore which are named the same.

One thing you could do so we are all on the same page is either post your VI with all the controls, or copy the entire front panel to a new VI and attach that.  That way we can also see the controls that are not behaving like you expect.

0 Kudos
Message 4 of 9
(3,729 Views)
Ok, for additional help, I made a duplicate of my main front panel with all the controls in it (but none of the code minus my simple code to grab all of the Control References.  Just run the main front panel once while having the enumeratecontrols.vi front panel open and you'll see it populate the final array (there will be some blanks at the top, scroll down to index 50 or so and you'll see all the labels.  It's sorted in alphabetical order to make the duplicates obvious.
0 Kudos
Message 5 of 9
(3,726 Views)
I just did that right before you posted, how amusing. 🙂

One copy of my main front panel is posted.  I've gone through great pains to make sure no controls have duplicate names.  They aren't supposed to because I use these references eventually for an automation script.  Some of the controls only exist once, at least according to the search function built into LV.  I'll try your blinking method and see what I find (I didn't even know a control could be made to blink).
0 Kudos
Message 6 of 9
(3,724 Views)
Ok, I tried setting the blinking property and I only have one control blinking (Amp 1 in my sample) even though the output array shows two copies.
0 Kudos
Message 7 of 9
(3,718 Views)
Ok I get it now.  I am glad you attached the panel.
 
So this seems to be a 6.0 issue and works fine in 8.2 etc.  But here is your issue:
 
The first thing you call is the VI controls, and then if they are in a tab you correctly go grab the tabs controls.  Well if a control is grouped, then when you call the VI controls property, you get a reference to it, even if its on a tab control.
 
So the problem is in your tab control you have controls grouped together.  So the first call to VI Controls actually gets a reference to those controls.  Then later when you grab the controls off the tab pages you end up getting another control reference.  So the assumption that you need to get the controls off the tab pages in slightly incorrect for LabVIEW 6.0, if the controls are grouped.
 
You can see this in a simple VI.  Drop a tab control and place 2 controls on the first tab.  Run the VI with your subVI and notice it works nice.  Now group the 2 controls notice it fails.  Now highlight execution on both and you can see that the array from the Panel>>Controls[] is 1 element the first run and 3 the second.
 
So you have a few workarounds.  First don't group and controls.  Second add code to your loop to check the names and if you already have seen this name ignore it.  Third upgrade LabVIEW.
Message 8 of 9
(3,711 Views)
Wow, thank you!  I would have never guessed that grouping would cause such a problem.  Unfortunately I can't upgrade LV right now because we don't really have the cash to spend on it so I'll just use the other workaround and ungroup them.  I really only grouped them for creating the front panel to make everything nice and neat.  I didn't realize it would cause a problem.  Everything's been ungrouped and the system is quite happy now, thank you so much.


0 Kudos
Message 9 of 9
(3,707 Views)