Handling a Large Number of Front Panel Controls in LV 8.6

[Tim_C.]

Starting a new project that will have a lot of front panel controls. 

Looking for some solutions / ideas so I do not end up with a large number of control references throughout the block diagram

being used to control enable / disable states and setting values.

One thought I had was to create references of each control and feed them into an array at the start of the application but then I would need to know the index of each control to manipulate it.

Is there a better way to handle a lot of front panel controls?

Thanks

Tim C.

[elset191]

I've made clusters of references before.  Takes out the whole index thing because you can unbundle by name

[smercurio_fc]

Define "a large number". I think your bigger problem will be massive slowdown due to lots of front panel updates. You should be looking into using the Defer Panel Updates property as well.

[Ben]

---

elset191 wrote:
I've made clusters of references before.  Takes out the whole index thing because you can unbundle by name

---

I take that a step farther for the large apps. I create an Action Engine to cache all of my control refs. For those massive visablity settings change operations, I included an action to handle all of the settings. I also include an action that lets me get the ref's and then use the Unbundle by Name to select the one I want now.

THe following images illustrates one of these AE's in use. The AE here is called GUI Controller and the two VI's with a heder that reads "GUI Cnt" are two of the wrappers (APIs) for the AE.

THe first one ""Collect" has a huge case setting the screen up for "Collection Mode".

The SEcond one "Get Refs" just returns a cluster of all of the refs and let me pick the one I will be using while in "Collection Mode". In the code shown below I am registering dynamic events for only the FP objects that are active while in Collection Mode.

I hope that helps,

Ben

[johnsold]

Tim C.,

You did not describe the programmatic changes to your front panel in much detail.

Would grouping the controls onto the pages of a tab control eliminate the need for many (all?) of the enable/disable changes and make a simpler user interface at the same time?

Lynn 

[Tim_C.]

Get Ref VI - To set this up do you simply

1.  drag a ref of each control into that VI

2. bundle it by name

3. then pass it out as a cluster?

[Ben]

This thread shows a short-cut to creating the cluster in the first place.

Then i save it as a type def.

And for those that knew all of tht already...

In the init case I convert the cluster to an array and check to make sure all of the refs are valid. If any are not (happens when adding controls later like you forget to wire the ref) I return an erro and prevent the app from even starting.

Have fun!

Ben

[Ben]

[set Proud G-Daddy mode]

One of my rookies* wrote an XControl that discovers all of the controls and indicators on all FP automatically and lets us do what I showed above without having to wire the refs to the cluster.

The hard part was figuring out how to implement it such that it did not put any dependacies on the caller.

I'll let the more ambish out there think abou that one for a while.

[Set Proud G-Daddy mode = False]

Ben

* My rookies are certified LV architects so don't get the idea this challnge is easy. and BTW, no scripting required.

[RobCole]

While it may not be optimal - You can open a reference to the front panel and pass that into subVIs. With that panel reference you can then get and set the value of controls on the front panel by name.

I did this back in LabVIEW 6i when I had a program with >300 controls on various tab pages. The block diagram looked like just a place to store terminals while the main program just got the local reference then had 3 subVIs (Init, Run, Shutdown). 

Here is open reference (by VI name),  Set Value and Get value (for a boolean):

[tst]

Also, here's a tool which greatly simplifies the creation of the cluster - select the controls you want, right click, select the option et voila - you have the typedef cluster already bundled.

If you want a simplistic example showing this kind of control, you can look at this one, but I assume you don't need it. Also, as mentioned in that post, I would probably have done things differently if it was real.

A couple of caveats to look out for:

• Make sure that you don't update the same controls from multiple places. If you do, be very careful in how you do it.
• If you do use the defer updates property (which you probably will), you should be careful to make sure that every defer has an undefer, or your panel will get "stuck".

---

Ben wrote:

One of my rookies* wrote an XControl that discovers all of the controls and indicators on all FP automatically and lets us do what I showed above without having to wire the refs to the cluster.

---

How does an XControl come into play when doing something like this? I suppose it's easier to use if you don't have something like the JKI RCF installed, but you could also just open it from the tools menu.