best practice to modify a large number of front panel elements while saving space in the block diagram

[Arun_Persaud]

Hello

here is my problem: I have a bunch of, say, indicators/graphs that I need to reset when I hit a button.  I do like to keep my block diagrams as small as possible, especially in the main vi (queue-based event driven, so 2 while loops one event handler and one worker). If I want to change any front panel element I, at the moment,  wire them up directly in the main vi which takes up a lot of space. It would be great, if I could just call a subvi "reset indicators". Is there a good way to access front panel elements in a subvi without having to hand over tons of references?

Or is it a good approach to create a cluster with references of all front panel elements during init and then have that in a shift register on the worker while loop and hand it to subvis? That's what I do at the moment to access all the hardware I'm using (e.g. during init bundle all "task out" and add the cluster to a shift register in the worker while loop). Perhaps I should have just one cluster (typedef) in a shift register that consists of other typedef cluster, one for data, IO addresses, front panel references, open files, etc. Seems like a common problem and something that I probably do wrong 😉

How to other people handle this?

cheers

Arun

[nyc_(is_out_of_here)]

I have a global VI with several 2-d arrays. What I did was pass the path of the VI to a subVI. In the subVI I use the Open VI Reference function and then use the Invoke Node and select the method ReInitialize to Default.

Your idea about using a cluster is also something I have done as well.

[mikeporter]

Pass a reference to your top-level VI to the subVI. With that you can get a reference to the top-level front panel which can give you references to all the controls on the front panel.

Mike...

[Arun_Persaud]

Just played a bit around with passing the top-level VI reference to the sub-vi. I'm using panels with tabs in it and it seems not that straight forward to get the reference for the control I want, that is I need to go through several layers of property nodes, cast to more specific classes along the way for the panels (which means I would need to change my code in case I add tabs or remove tabs?). But perhaps I'm missing something, since I never done this before... is there an easy way to say "find control named foo" while just handing over a vi-reference?

Getting reference in the main VI and adding them to an array or cluster seems a lot more straight forward. Is there a reason to do it the other way (easier to maintain/portable and adding new controls in the future)?

Thanks already for the feedback... already learned some new things about labview 😉

Arun

[odiseo123]

Hi.

To your question of finding control references by name, there is a set of functions in LAVA which do what you need.

http://lavag.org/topic/10279-discuss-get-reference-to-all-controls/

The function to use and its description:

Get Control Reference by Name.vi
-Polymorphic VI that allows for searching list for single reference or an array of references.
-Gets a Specific Reference from the List of All Controls by Control Name(Label).

You need to pass it an 1D array of references, which can be generated by the VI "get references to all control". The advantage of this vi is that "Allows the VI to dig down thru Tab Controls to Get all References and Names from the Tab Controls" which is one of the problems you were having.

[Ben]

I have shifted toward what I have been calling a GUI controller design pattern. YOu will find images of a GUI controller in some of my code in this albumn. Note, there are links below those image that take you back to the original tread where they were posted.

I prefer this approach because it let me develop what I have been calling "Thin GUI"s where the is just a skin over the under-lying code. This approach lets me change the quickly from "Tester"s to running code.

The GUI controller puts the responcibility of identifying control ref on the GUI rather the sub-VI. As you have noticed changes to the GUI can affect a sub-VI's ability to find the control if changed. The GUI controller concept only accepted defined control refs when Init. The type def'd cluster  that stores the control refs, knows the control types so prop node conversions in the sub-VI is not required since each ref is defined. It also has a side benefit that you can detect issues with ref types and compatablility issue at development time. YOu don't have to wait until your code finds that "one corner case" where a sub-BI had to be modified to adapt to a change in the GUI.

That's just my two cents,

Take care,

Ben

[Arun_Persaud]

Thanks everyone for all the information, got some very helpful tips. Managed to hand over the references to my subvis and my main vi got a lot smaller and easier to read now.

regards

Arun