01-14-2015 09:16 AM
Hi,
I just tried to program something wih a sequence but it seems I am pretty unfamiliar with basic LabView things. So I am asking for help.
What I want to do is after program start wait for the button to be pressed, then light the LED for one sec and then wait for the button again to finish sequence and program execution. Please see the VI attached.
I found out that placing the button outside the while loop will not sample it in the loop. But if I place it inside how can I sample it in the other loop. Or do I need a completely different approach?
Thanks for any help
Martin
Solved! Go to Solution.
01-14-2015 09:31 AM - edited 01-14-2015 09:34 AM
Your VI is broken because you cannot wire from two separate frames of a sequence to the same indicator.
That's a conflict.
It looks like what you are trying to do is:
Wait until switch is ON.
Turn on Light.
Wait 1000 mSec
Wait until switch is ON.
Turn off light.
The quick way out is for you to use a local variable for the Light. Create one and use it inside the frame, just like a terminal.
Although you might have other problems waiting (if you don't turn the switch OFF during that 1000 mSec, the second WAIT will be real short.)
There are better ways to do this, though.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
01-14-2015 09:33 AM
Martin,
LV is a "Dataflow Programming Language". That being said, the block diagram reflects data sources and data sinks and how they are connected.
One basic rule says: A function can execute as soon as all inputs receive valid values, once it finishes execution, it will pass valid values to all its outputs.
Following this sentence, you can get rid of the sequence structure.
Other buzzwords you are looking for are:
- state machine (architecture)
- timing loops
Did you work through any LV classes or "getting started"?
Norbert
01-14-2015 09:37 AM
One basic rule says: A function can execute as soon as all inputs receive valid values, once it finishes execution, it will pass valid values to all its outputs.
And that is true for every structure in LabVIEW *-EXCEPT-* the flat sequence. I don't know why they chose to break their own rule there, but they did.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
01-14-2015 09:58 AM
Steve,
i don't know if that is true, but i think that the flat sequence structure is handled internally as a "defined execution order of single frame sequence structures". The stacked sequence structure is handled as a single node regardless of the number of diagrams in it.....
Nevertheless, sequence structures should be avoided except for some rare incidences where they are really useful (single frame).
Norbert
01-14-2015 10:15 AM
From one newb to another. I just learned about this last week and work better with examples.
So here is a simple state machine to get you started.
I recomend whatching some tutorials about how to make them.
It will better help you understand what is happening and why.
01-14-2015 10:21 AM
CoastalMaineBird wrote:
And that is true for every structure in LabVIEW *-EXCEPT-* the flat sequence. I don't know why they chose to break their own rule there, but they did.
I was doubtful as well but according to documentation:
Data flow for the Flat Sequence structure differs from data flow for other structures. Frames in a Flat Sequence structure execute from left to right and when all data values wired to a frame are available. The data leaves each frame as the frame finishes executing. This means the input of one frame can depend on the output of another frame.
So i guess this means that as long as all of the inputs to the next frame are available, it will commence even though all of the code in frame 1 is not complete. Makes me more leary of this structure.
01-14-2015 10:28 AM
So i guess this means that as long as all of the inputs to the next frame are available,
But it's not just within frames, it's the whole bloody thing. Try this snippet - you'll notce that one of the displayed times is way later than the other.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
01-14-2015 10:57 AM - edited 01-14-2015 10:58 AM
CoastalMaine
Maybe I need some more coffee this morning but I think you are going to need to spell this out for me. I ran your snippet in 2013 but it just looks like the difference between the two timers is 1000ms which should be expected because there is a 1 second wait between the execution of the first and last state so I am not sure what is unexpected exactly
01-14-2015 11:16 AM
@CoastalMaineBird wrote:
So i guess this means that as long as all of the inputs to the next frame are available,
But it's not just within frames, it's the whole bloody thing. Try this snippet - you'll notce that one of the displayed times is way later than the other.
The snippet you posted would match data flow as you'd expect. You wait until you get all of the inputs to the frame. The top frame receives the input roughly a second before the bottom frame. Why wouldn't you expect one displayed time to show later than the other? You'd be showing a break to data flow if you showed them being the same general time.
As far as the original poster, if you are unfamiliar with basic things, you should start with basic structures rather than a more advanced structure. The sequence structure isn't a basic structure. It's designed for very specific corner cases or FPGA programming. Don't be quick to use either the sequence structure or local variables. Yes, both have a purpose. What you're trying to do doesn't really have a need for either. You don't NEED a completely different approach. But, you should definitely look at another approach.