06-22-2015 09:35 AM
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.
Solved! Go to Solution.
06-22-2015 10:23 AM - edited 06-22-2015 10:26 AM
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> ---'
06-22-2015 10:28 AM
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).
06-22-2015 11:35 AM
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.
06-22-2015 11:50 AM
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> ---'
06-22-2015 11:50 AM
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).
06-22-2015 12:17 PM
Where to begin? There is a lot of "Bad Bad Bad" things going on here.
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!
06-22-2015 01:39 PM - edited 06-22-2015 01:42 PM
@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!) 🙂
06-22-2015 03:28 PM - edited 06-22-2015 03:31 PM
@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> ---'
06-22-2015 03:37 PM
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.