LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

For loop won't start or won't stop depending on the toggle switch

Solved!
Go to solution

Attached is the VI I am working with. The VI is a bit lengthy but the two For loops on the left hand side are the loops that are having issues. When the program is running and I hit the toggle switch "CYCLE START" the loop simply does not run. However, when I have the toggle switch on before the program starts, the loop will run how it is supposed to, but won't turn off when the switch is put in the OFF position.  Any help is appreciated. Thanks.

0 Kudos
Message 1 of 12
(2,860 Views)

LabVIEW relies on data flow. Everything get's read as soon as possibe going from left to right.

 

So when your program runs initially, it just pulls the initial value of "CYCLE START" and then goes. It doesn't wait for the button to be pressed or go to True or anything.

 

There are multiple ways to fix this... the best of which is to re-do your code. That block diagram is rediculous. I would suggest utilizing one of the sample achitectures that ships with LabVIEW (Queue'd Message Handler?) and put a lot of that code in subVIs.

Alternatively... the quick fix is to put a while loop around CYCLE START, with a 100ms delay, and wire the boolean to the stop terminal on the loop. This will make the application wait for that loop to end before the rest of it goes. (A better way to do this is with an event structure, but in this instance you don't need it, so that's a lesson for another day.)

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 2 of 12
(2,847 Views)

Your case statements are only evaluated once at the vi-startup. More specifically, when the vi starts with the switch off: 'CYCLE START' is evaluated as false, this value will propagate to both of the case statements that it is connected to which means your For loop will not run. 'CYCLE START' is never re-evaluated, so your For loop will never run (when your vi is started with 'CYCLE START' off).

0 Kudos
Message 3 of 12
(2,836 Views)

James,

 

I believe I have done what you have asked as far as the quick solution option goes. This solution (if I have done it correctly) now opens a whole other box of worms. When I run the VI no measurements are recorded until the CYCLE START button is triggered. Also still the loop does not finish with I toggle it off. Again thanks for any help on this discusssion.

0 Kudos
Message 4 of 12
(2,814 Views)

Alright, so like I said before the data flows left to right, so stuff on the right can't/won't do anything until the stuff on the left finishes. In this case, that means nothing that reads from your boolean is going to run until that new While loop is done. Since you're wiring that boolean to that other loop (gigantor-loop), gigantor-loop will be waiting on that boolean as well.

 

Are you planning on having the CYCLE START button be pressable multiple times? If so, you'll need to put the while loop around that CYCLES case structure too so that it waits for you to press that button again and again instead of stopping when you press. If you need that CYCLES START value inside gigantor-loop,  then you need to use a local variable. Careful here, though, because you WILL run in to race conditions.

**Let the record show that I don't suggest using this code as it is. Having this number of parallel loops and different case structures is a very strong push to use a queue'd message handler and/or a state machine architecture. All tips that I am giving here are for the purpose of making the current code functional, but will difinitely not make it more usable or easy to build on in the future.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 5 of 12
(2,804 Views)

Hi Emart, you are correct, nothing will happen until you make that CYCLE START control say TRUE. If you press the light bulb in the block diagram it will slow things down and show you what is executing. In this case, your main while loop(s) are waiting for the CYCLE START value, which is not given to them until your new while loop is finished. If you want your main while loops to respond to button presses, then the event structure is the way to go, as suggested earlier.

 

If you want those while loops to check the value of CYCLE START during each iteration, you can create a local variable of CYCLE START so they are not waiting on the the data wire to start executing. However, with the local variable you only get to press CYCLE START once during your whole program because the the the for loop can only be started once. (The local variable will reflect the current value on each iteration though).

0 Kudos
Message 6 of 12
(2,803 Views)

Where to begin?  There is a lot of "Bad Bad Bad" things going on here.

 

  1. How many loop conditional terminal booleans are driving a subsequent case structure?  If the conditional termials are "Stop When True" the boolean will be TRUE when the loop finishes and all the False cases are "Dead Code"
  2. Why both a Guage and a numeric indicator for RPM? Just customize the gauge's digital display.
  3. You seam to have the wrong mechanical action on many booleans
  4. NEVER Create and destroy DAQmx Tasks inside any loop
  5. Those "Incrementing" For loops timing requires MANY controls to be EXACTLY set with each other to "Semi-Synch" the for loops and the DAQmx Tasks and the DAQ Assistant really really REALLY needs to be converted to "Code" before you have any hope of syncing the loops

Or, you have a tremendous opportunity to improve that code.  You also have LabVIEW 2013 so, The "Finite Measurement (NI DAQmx)" and "Contineous Measurment and Logging (NI DAQmx) Project Templates are right there with walkthroughs to help explain the concepts that it takes to do these types of projects easilly!  


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 12
(2,793 Views)

@James.M wrote:

Alright, so like I said before the data flows left to right, so stuff on the right can't/won't do anything until the stuff on the left finishes.


I've seen you say this twice now, and it's just not true.  Data flows from the output of one node to the input of another.  Usually this means "left to right" because it's wired that way.  If you had two subVIs, "A" and "B", not wired together and "B" is to the right of "A", it does NOT follow that "A" will execute before "B".  If, for some idiotic reason, you had the outputs of "B" on the left and the inputs of "A" on the right, you could wire the outputs of "B" to "A" and the data would flow right-to-left.

 

But I'm fairly certain that I have misunderstood the information you were trying to impart?  (It wouldn't be the first time, believe me!)  🙂

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 8 of 12
(2,769 Views)
Solution
Accepted by topic author emart

@billko wrote:

@James.M wrote:

Alright, so like I said before the data flows left to right, so stuff on the right can't/won't do anything until the stuff on the left finishes.


I've seen you say this twice now, and it's just not true.  Data flows from the output of one node to the input of another.  Usually this means "left to right" because it's wired that way.  If you had two subVIs, "A" and "B", not wired together and "B" is to the right of "A", it does NOT follow that "A" will execute before "B".  If, for some idiotic reason, you had the outputs of "B" on the left and the inputs of "A" on the right, you could wire the outputs of "B" to "A" and the data would flow right-to-left.

 

But I'm fairly certain that I have misunderstood the information you were trying to impart?  (It wouldn't be the first time, believe me!)  🙂


 

Ah, point taken, I'll have to adjust the way I explain data flow, not just best-practices data flow. It's hard to describe data flow to a newbie without using directions. I was just trying to impart that the boolean he has wired up is supplying data to both the first case structure and the main While loop, which means they are both waiting for the info from the boolean. If he makes the application wait for the user to click the boolean, then the While loop will be waiting too.

 

I think data flow is one of the biggest problems new users seem to struggle with and this thread is an example of that. Emart can make this code work, even if it's a mess, but I think he's gotten to where the code additions have gotten out of hand to the point where he needs a little more experience/help to understand how to encorporate more functionality without messing up what's there already.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 9 of 12
(2,744 Views)

Thanks everyone, all points taken.  We realize this is a mess, now it is time to clean it up and or start over.  Thanks again.

Message 10 of 12
(2,731 Views)