create a menu

[NXTenergy]

Hi,

I tried to find an answer to this but so far, have had no luck. I am looking to build a vi  where the user will be able to select from a couple of different menus one after another which will tell our machine what to. I can use buttons for each selection, but would rather use a menu with the choices (I think I should be using a case structure in code) but I can't find how to generate a menu on the front panel to link with my case structure.

Thanks for your help.

Jake

[Harold_Timmis]

you may be able to use a state machine or maybe even an while loop with an event structure withing it

[Darin.K]

You can use any of the controls on the 'Ring and Enum' palette and a Case structure.  I usually prefer the enumerated type since the labels show up on the Case structure and you can auto-generate all of the cases.  I assume the choices in the second menu depend on the choice made in the first.  In a ring control, you can just wire different string arrays to the 'Strings[]' property of the second ring.   This can't be done with an enumerated type, instead, you would need multiple controls and programmatically control the visibility.  Here is a simple example with two menus, the second menu shown depends on the choice made in the first.  

[smercurio_fc · Accepted solution]

The example provide by Darin has two major flaws:

• Embedded while loops inside of case structures which is inside of a while loop - this is usually a bad idea.
• No small delay in the while loops. This causes LabVIEW to spin around like crazy doing absolutely nothing, and chewing up 100% of the CPU while it's doing nothing. 

The code can be written more efficiently (and cleanly) using an event structure.

It's not clear whether you're looking to change the items in a second menu based on the choices of one, but if you are, then the attached is an example of doing this.

[NXTenergy]

Thanks guys,

That is just what I was looking for.

[Darin.K]

In my haste to post a sub-vi free example I left out my wait sub-vi.  I should have replaced this with a call to the standard wait vi.  I use this version since it is more compact and for most cases I use the default 150 msec.  Oops..

 Embedded while loops inside of case structures which is inside of a while loop - this is usually a bad idea

I have dozens of state machines with while loops in one of the cases, and I use enumerated types whenever possible.  It would never have occurred to me to be a problem, I guess you learn something everyday....

[RavensFan]

Darin,

I have a recommendation for your wait VI.  Add an Error in and Error Out which you just wire through from control to indicator.  This way if you need to enforce a wait period between two other subVI's, you can just use the Error Wire to enforce the order of execution.  This will help prevent unneeded sequence structures.

[Darin.K]

I also have a 'delay' vi with error in/out and default 250 msec.  No real reason to have two different ones I suppose, except that I found that for GPIB delays I usually needed a slightly longer delay than I prefer for GUI waits and I wrote most of these 'shortcut' VIs to require minimal inputs.