Button works once....but not twice!!! What gives??

[ShogunOrta]

So this program is a part of another program. Basically, it should work in that the user inputs a specific entry into the Mode string, and depending upon what that entry was, when the user presses the "Optics" button a separate subvi is opened depending on which entry the user input to the "Mode" string. And....this works the first time. But then if I choose a different entry for the Mode string, the entire program locks up. 

I've attached the beligerant code here. To test, within the Case structure choose a case and then direct the invoke node stuff to one of your own file paths. And pay attention to the case structure cases since that's what you have to input to the Mode string. Go ahead and rename them if that makes it simpler. Thanks.

[mcduff]

I think your problem is having two event structures in the same while loop. (Typically you should only have one event structure to handle UI interactions per block diagram.) I have not tested you VI but think dataflow:

Your while loop is waiting for an event to occur before completing its loop, in your case two events have to occur before the while loop finishes an iteration. Why not combine both events into one event loop and test that? Why do you need two event structures? If you need two event structures, then you need two separate while loops.

mcduff

[crossrulz]

Use only 1 Event Structure in your loop.  You can have many event cases with a single Event Structure.  So make an event case for each of your buttons.

[paul.r]

As others have said, get rid of one of the event structures, and put everything in one. 

Also, get rid of the false constant wired to the loop condition - how are you going to stop this VI? Using the 'abort' button is like using the task manager to kill an application - it should be a last resort used when a bug caused your program to freeze, not the default method. 

I would also recommend reworking your case structure layout - you've got code duplicated in 9 different case structures to run a VI, when the only thing that is changing is the VI you are running (the path). Instead you could use a drop down box for the mode, and map the modes to an array of paths, and use the mode selection to index the array. (Although I wouldn't hard code the paths either.)

[aputman]

In addition to what mcduff said (which should fix your problem), you might try changing the mechanical action on the buttons to Latch When Released.  This will cause the value of the control to be reset after it is read.  But in order to read the value, you need to move the terminal for each button into the corresponding event so that when the event is triggered, your code associated with the button will be run but also the terminal will be read.  It's the reading of the button that resets it back to false. Now, you can eliminate several local variables.

You also have a lot of duplicate code inside the case structures.  The only differences are the path to the VI and the constants for the Run VI.

I won't finish this sentence because Paul beat me to it.

[Tapan_Mojidra]

In order to solve issue you should combine both event structure or 

you have to add timeout case and time out period for both the event structure. That will work.

Please find corrected vi for the same.

[altenbach]

---

@ShogunOrta wrote:

I've attached the beligerant code here.

---

There are many things wrong with this code, starting with the incorrect mechanical action of the buttons. One was "switch action" and one was "switch until released" (I hope you know the difference!). You reset each via local variables, which makes absolutely no sense for the "switch until released" which goes false once you release it, firing another event. Both need to be "latch action" and their terminal inside their event. This way they reset once the event fires and no boolean local variables are needed at all.

There is way too much duplicate code, for example the entire train to start a VI is nearly identical differing at most by a path and a single boolean. You only need one instance of that entire code segment!

Yes, "Mode" could be an enum, radiobutton control, or listbox with all allowed entries predefined. (not shown). You could even use it to index into an array of paths, eliminating one of the case structures.

I assume that your globals inside the disable structure are for future expansion because they make no sense where they currently are. Again eliminate the locals and wire the controls directly. If these are operated by the user, they need to have their own event case. You should also never hide the labels of the globals, currently they all look the same and wiring errors are easy to occur and nearly impossible to find later.

You need to clean up the diagram. One of the terminals was about 20 screens over, away from the main code. (look at your scrollbars!)

Use a reasonable font for the terminal labels. If your eyes really need that gigantic font, you would not recognize the rest of the code anyway.

There are many more issues. To give you some hints, I did a quick cleanup. Modify as needed.