LabVIEW
Event Structure/While loop
Solved!
Show us some code!
Events typically are for user interactions, not for algorithms. Also local variables are typically for UI tasks, not computations.
What is your program supposed to do? Let's start here!
Yes, you need to start with more tutorials. 😄
- If these booleans come from a daq reading, you don't need an event structure.
- Get rid of the local variables and connect the controls directly to the indicators (lower right). You also need to ensure that the indicators are only updated after the event has fired. Right now, they update with the old values while the event structure is still waiting.
- Many cases seem identical, so you need only one case each (name it e.g. 1..6 and make the other the default)
- reading a local variable (e.g. "boolean 2" or "boolean" (also in the lower right) and writing it to its own terminal makes no sense. You are also writing to these terminals (via local variables) in the case structure above in parallel, so whatever writes last wins and the outcome might not be as expected.
- Your event structure prevents the big loop from spinning.
- You could dramatically simplify your code by using arrays of booleans. (8x less code!).
- You are only dealing with integers, so all orange wires should be blue instead.
- ...
Regarding the Event Structure stopping the While Loop from spinning - the while loop will only start the next iteration (i.e. loop) when everything inside itself is finished.
The event structure only does something when one of the 13 cases you've specifically given happens - and since you've set the timeout to '-1', the timeout case never happens (so you could delete that case for timeout = -1 always, or you could make it so the event loop can timeout.) In this case, it seems like maybe you would want to change the timeout value to a small(ish) positive value, but as altenbach mentioned, you might not need it at all if you restructured the code (depending on the real source of input).
Regarding the top Case Structure, you have many cases with the same content as altenbach mentioned, but moreover, each contains three more case structures where only one will ever execute, and the one chosen only changes the timer value. Since this is all the same code in each case, a subVI seems like a good choice, but I've placed below a snippet (you can drag and drop it onto a block diagram) that shows both altenbach's suggestion of grouping the cases, along with some simplification of the cases themselves. The 0 and 7 cases are also joined (with each other), because they also only change the timer value.
