Updating a lot of indicators

[jyang72211]

I have a lot of indicators on my front panel.  If I were to update them on my BD, my BD will be a little bit too large.  I was thinking about updating the indicators in a subvi, but I would have to feed in all references of the indicators, which will required too many terminals.  Is there a way to create a reference for the complete front panel of the main vi and feed it into a subiv and get all the references of the indicators based on just one reference of the main vi within the subvi?  

[altenbach]

Yes, but that would be also pretty convoluted. How often do you need to update?

Maybe you can use a couple of arrays of indicators?

Even a table or listbox, for example might work.

[BenBabb · Accepted solution]

I had to do something similar once.  This is how I coded it.  On my application there was a tab that contained indicators.  The key for this to work is the label name for all your indicators had to start with "bol".  You could do the same thing with buttons as btn etc.

[jyang72211]

I need to update the indicators about once every 30 seconds.  I don't want to put the indicators in a cluster or an array (different types), since I want to have the freedom to move each indicators individually for asthetic reason. 

[pincpanter]

Indicators within a cluster can actually be moved to arbitrary positions - into the cluster rectangle of course. If you update all indicators at once, joining them into a cluster would be the best way IMHO.

[Ben]

One of the challenges of pushing GUI updates down into sub-VI is that you end up with very tight coupling between the two so that a change in one may require a change in the other.

The approach I have been using quite a bit is a GUI controller.

It is often a Action Engine that uses a cluster to cahe all of the references so the GUI can be touched from any place I want.

Here it is init (see VI label GUI cnt init)

where all of the ref are checked to makes sure they are valid. (Note: see size of horizontal scrool bar to give you a hint that I have a state machine prior to this loop that builds my cluser of refs.)

Note: the validity checks helps a lot with the coupling because it is effective a sanity check on ME and reminds me I forgot to bundle the ref of that new control I just added.

Action are implemented in the Action Engine to do GUI stuff...

Note: Obesreve verticle scrool bar to get an idea of how many controls are getting touched.

or if I want to just get at the refs, I have an action that lets me select the ref I want by name.

I hope that helps,

Ben

PS: Sorry for the broken record.

[jyang72211]

Hi Ben Babb,

Can you attached the code in LV 2009?  Great solution.  Thanks!

Yik

[jyang72211]

Hi Ben,

Thanks for your detail explanation.  I am still digesting at the moment.  On the first picture, you were putting the reference in a cluster through a loop.  Can you post that picture too?  On picture 3, I see a bunch of subvi that you connect your error to (with a vertical arrow on it), are you using them to merge error?  How does it work?  Thanks!

yik

[Mark_Yedinak]

One does have to ask though if all of the indicators are truly needed. If you have that many indicators on the front panel is your UI easily understood by the user? Overly complex front panels that provide every bit of information possible are not always the best. They can be very difficult for the user to understand. Perhaps you can display only the critical data and then allow the user to specify when they want to see more details.This level of detail would be deisplayed on demand when needed, not at all times.

[Ben]

The cluster of refnums is built in a state machine (very boring) that has three states "Bundle Collect" that goes to "Bundle Analyze" that goes to "Bundle Design".

Yes I am merging error cluster.

Serach this site for "Error Fork Stacker" to find Mike Porters thread where he posted the code that does the stacking.

Ben