Having a boolean switch/button turn-off automatically

[mrbebu]

Hi my attached program controls (ignore the ? marks.  Those are just analog output signals and my home comp doesn't support the DAC board i'm using in the school lab) a water pumping device that pumps out a specific amount of volume based on what the user entered.  Since i'm completely new to labview, i'm having difficulty setting up a boolean switch that when pressed will run the while loop until the while loop conditional is false.  I want the boolean to shut-off automatically once the while loop condition is false and with it the devices that are getting a signal from labview.  

As of now, i just hit the run button on labview so it doesn't look very nice.   When i'm demonstrating the device, i would like to have a nice big boolean button to activate the device on the front panel once a user inputs a volume, not some little tiny arrow button in the top left corner of the screen. And then of course, have it turn off automatically once the volume is dispensed.  

Thanks in advance,

T 

Oh also, how do i change the boolean LED color from green to red?  I have LEDs on my actual device but i want them on my front panel as well. 

Message Edited by mrbebu on 12-13-2008 09:03 AM

[tbd]

Hi mrbebu,

      By your description, a very simple program might do the following:

1) Wait for START button press

2) Start Pump

3) Wait for Timeout (calculated from requested volume)

4) Stop Pump

5) Goto step 1

The "Loop" from step 5 to step 1 suggests that steps 1 to 4 might be put in a loop like this:

Sometimes it's nice to be able to abort a process before the Timeout has been reached - requiring modifying (or completely replacing) the example above! (this is just to get you started   )

Re Missing Hardware (at home): MAX will let you create Simulated Hardware - so you can write your application with all the calls to the hardware - even if it's not installed!

Cheers. 

Message Edited by tbd on 12-13-2008 12:37 PM

[altenbach]

A proper finished application is always running and does not even show the toolbar. It is set to "run when opened", possibly starting in a wait state unitl a front panel button is pressed to go to some other state.

You should implement this as a state machine.

You should use a latch action boolean for the button, it will reset to false automatically once it is read by the code.

Question: Is the user allowed to change the volume while the loop is running?

Question: Isn't it sufficient to turn the pump on once and just do the timing or do you constantly need to send the same commands over and over at a fast rate?

You can color your LEDs any color you want by using the coloring tool.

Your outside case structure is not needed, because the selector value is always the same. It can only be false because it needs to wait until the while loop finishes and that can only happen if the value is false.

Use data dependency via the error cluster for things that should happen after the loop and things will automatically happen at the right time.

What is the loop rate of the while loop. You probably want some pacing there.

Don't hide wires under structures (lower case structure)

Don't wire right-to-left (upper right device controls)

"Stop if true" is often logically more natural than "continue if true", just flip the comparison.

Please attach your real VI and somebody might give it a workover. 🙂

[tbd]

I may disagree with Altenbach with respect to one minor point here: (sorry Altenbach, I really appreciated your Kudos in another post, and don't want to disagree with you! , however...)

---

altenbach wrote:

You should implement this as a state machine.

---

While a state machine can implement just about any logic, it hides the logic (like a stacked sequence.)

The State Machine is often used to implement a very simple sequence of steps - in these cases I think a State Machine is a bad idea as it hides the simplicity of logic.

If you start using a State Machine for everything (because you can) you'll eventually find yourself tangled in the proverbial "spaghetti logic" caused by the infamous "GoTo" - because that's what's happening when the state machine goes to the next "state".

A State Machine is like a pair of vice-grips - everyone keeps it in their tool-box, though there's usually a better tool for the job!

Cheers!

Message Edited by tbd on 12-13-2008 01:37 PM

[mrbebu]

Thanks tbd.  I'm going to look into what you have setup.  

I'm also unaware of MAX.  Can you fill me in further?  I'm not sure that i have such a thing because i'm using a student edition and it's the MAC version. 

[altenbach]

---

tbd wrote:

I may disagree with Altenbach

---

I don't think we really disagree here, because a state machine can mean many different things to many people. We already have an event structure, so having a few event cases, (one for each state) does not really hide much code, you simply only see only the code for the current state of interest.

• The program needs to start up in a wait "state", so we simply use a timeout of -1 and nothing happens.
• Entering the numbers, etc. also does not need any state or event, The control keeps the value until the code needs it.
• We have one event for "go" which sets the timeout to e.g. 100ms.
• Now the timeout case starts repeating. Here we update the progress indicator and check for elapsed time.
• Once the time has elapsed, we set the timeout back to -1 and we are all set to start over.

This problem certainly does not need any elaborate Rube Golbergian state machine. 🙂

There are two states (1) data entry, (2) pumping.

Since it has states and conditions to switch between them, it is already a "state machine" in the most general interpretation of the term. That's all I meant. 🙂

[mrbebu]

What is that loop structure around the "start" button? Please be patient with me:)

[RavensFan]

It is called an event structure.  It waits for an event to occur and executes the code inside based on that event.  In this case, it waits for a value change on the Start button which would happen when your press it.  The code inside that event executes which is just reading the button.  That causes the button to pop back up due to the latching action on it.

[mrbebu]

I got it working, thanks.  

Also, why would i want to start the pump separately from the timing event?  I feel like that is an extra sequence that is not needed.  

Regardless, I think i've got it working now.  Now i just hope that this different setup doesn't affect the timing calibration i've configured for my device. 

[altenbach]

One of the problems with the sequence is the fact that you cannot interrupt the wait and you cannot have a visible progress update.

Both problems can be easily solved if you don't use a sequence, but recruit the timeout case for the pumping duration. Here's a simple draft. See if this makes sense. 🙂