LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

stop the program once any botton is pressed

 

using logic gates or what else ?

 

0 Kudos
Message 1 of 9
(2,730 Views)

My eyes bleed.

 

Take a look at using an event structure to respond to user interaction.  Hey the event even gives you a reference for the button that triggered the event.  That might simplify that nested case eyesore.

ledh_BDJJB MOD.png


"Should be" isn't "Is" -Jay
0 Kudos
Message 2 of 9
(2,720 Views)

 

how to set the indicator value to null when the program is stop ?

 

0 Kudos
Message 3 of 9
(2,699 Views)

@416E64 wrote:

 

how to set the indicator value to null when the program is stop ?

 


Which indicator?  And what exactly do you mean by "NULL"?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 9
(2,686 Views)

Well, if the program should stop once any button is pressed, you could OR all buttons and wire the output to the termination condition.

 

Still, there are many things wrong with your program. Is this supposed to be a subVI that returns something? Typically a stopped program is pretty useless. It might be better to implement a state machine so the VI goes to an idle state, for example.

 

Problems:

  • Race condition due to the overuse of local variables. There is no way to tell if the local variable at the bottom is written before the local variable near the top is read by the code, but the outcome critically depends on the order. Why don't you wire the output of the case pyramid to the input of the upper part, eliminating two locals and the race condition.
  • A hidden control just to hold data is never needed. Use a shift register or feedback node.
  • Why is your front panel and diagram maximised to the screen? Makes no sense!
  • Your hidden control is zero by default, making the lower left LED light up on the first run. Is this really what you want?
  • Your VI spins millions of times per second consuming 100% of a CPU core. There is no way you can press the buttons this fast, so a 50ms wait would be sufficient, lowering the CPU use to basically 0%.

Here is a quick modification that shows how to eliminate the case pyramid. It stops when "take" or "put" is pressed, but not for the other buttons. Modify as needed.

0 Kudos
Message 5 of 9
(2,677 Views)

 

thanks again.

 

now the buttons are used to control the following statement,

but the whole program could not be aborted by the stop button.

 

Unnamed.jpg

0 Kudos
Message 6 of 9
(2,656 Views)

You probalby need to create an event for the stop button.

 

Get rid of these unneeded sequences (use the error wire to define dataflow) and local variable (wire across structure boudaries)

 

place the IO stuff inside the currently visible event case, because it does not need to happen when you press stop.

0 Kudos
Message 7 of 9
(2,619 Views)

@JÞB wrote:

My eyes bleed.

 

Take a look at using an event structure to respond to user interaction.  Hey the event even gives you a reference for the button that triggered the event.  That might simplify that nested case eyesore.

ledh_BDJJB MOD.png


I would not use a while loop 🙂 (assuming no other event needs to be triggered)

-----

The best solution is the one you find it by yourself
0 Kudos
Message 8 of 9
(2,596 Views)

@P  Use the while loop.  When you need to expand the UI it'll be done already ( this vi sourced from your New.. Subvi\Frameworks\UI-Events.vit anyway right? so the loop cost you nothing)


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 9
(2,591 Views)