LabVIEW
case structures in side event and while
Solved!
Hi new123,
@newmemeber123 wrote:
when i turn on 2 conditions the Vi is crashing.
You made something wrong…
@newmemeber123 wrote:
is there any other way to control them with boolean buttons?
Sure.
When there is a problem with your VI then you should attach that VI!
There is no way to help you without seeing your VI and an exact description how you are operating it, what you see, and what you expect to see instead.
- What is inside what? What are the events?
- What is "it" that you are controlling? (one case structure? events structure? all structures?)
- In the second sentence you are talking about buttons. What is the mechanical action setting?
- What are the two conditions? (Any two? any two in a specific order?, etc.)
- What is your definition of "crashing"? (program locks up? program disappears? computer crashes? computer bursts into flames?)
- What is "them" that you are trying to control?
- What is the purpose of the VI?
Hello, @newmemeber123. What an unfortunate name you chose for yourself -- I hope that with a little work on your part, and maybe some help from the LabVIEW Forum, you will become a skillful LabVIEW user.
Has anyone explained to you the concept of a Data Flow language such as LabVIEW? Here are the key concepts:
- Data travels in "wires" from Controls and Structure/Function outputs (by convention on the right side of the Icon) to Indicators and Structure/Function inputs (left side of the Icon).
- Structures/Functions don't start to run until all of their inputs have data,
- Structures/Functions don't exit until all of their outputs have data.
- If there is no Data Path ("wire", possibly with Structures/Functions strung along it) from one set of LabVIEW code to another, you can't tell which one executes first. LabVIEW is coded so that the two "data-isolated" pieces of code automatically run in parallel (to the best of the CPU's ability).
One place this is shows up early in LabVIEW is when learning about the Event Structure. This is typically used to help program the User Interface, with numeric, string, and Boolean inputs -- you can define an Event for, say, a Boolean "Stop" button that does nothing (and takes essentially 0 CPU time) if you don't push Stop, but jumps into action and does whatever you program in the "Stop Button, Value Changed" Event case.
You want the Event Structure to always be running. So you put it into a While Loop, and (initially) don't wire anything to the "Stop" indicator of the While Loop (this will, of course, cause LabVIEW to show a "Broken Arrow", meaning you have an Error in your code). Now create the above-mentioned Stop Button Value Changed Event, put the Stop Control inside that Event case, and wire it out of the Event structure and onto the While Stop indicator. This stops the Event Structure.
The rest of your code goes into a second While Loop that many LabVIEW developers put right below the Event Loop. As long as no output from the Event Loop goes into the second While Loop, the two loops will run in parallel. Do the rest of your code in this second loop.
And now you have the interesting question, "How do I stop this second loop?". Well, here's a trick -- instead of putting the Stop Control inside the Event Structure, put it inside the "main" While Loop and wire it to the Stop button. But now how do you stop the Event Loop? Well, you execute its "Stop" Event when Stop Value Changed happens, i.e. when you push Stop. So just put a "True" constant inside the Stop Event case and wire it to stop the Event Loop, letting the Stop Button, itself, stop the second While Loop.
Here's an example of the World's Simplest Event Structure. The bottom Loop is a millisecond Clock that tells you how many milliseconds the program runs. For Extra Credit, predict the value of Event Count when you push Stop to end this program. Did you get the same answer as LabVIEW shows you?
Bob Schor
