LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Newbie needs help on sequence

Solved!
Go to solution

All other structures hold their outputs until the whole structure is completed.  This one does not.  Each frame within the sequence appears to be considered it's own structure even though they are all linked together in a seemingly bigger structure. 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 11 of 23
(929 Views)

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.

 

No, you wouldn't. There is no other structure where one output of the structure is available  a whole second before another output of the same structure.

 

Not one.

 

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 12 of 23
(922 Views)

 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

 

No other structure can have two (or more) outputs that become available at different times.

 

Not one.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 13 of 23
(921 Views)

there is a 1 second wait between the execution of the first and last state so I am not sure what is unexpected exactly

 

Run it as is, and you see a 1000 mSec difference in the displays.

 

Convert the FLAT sequence into a STACKED sequence and notice the CHANGE in behavior.

 

THAT is what is unexpected.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 14 of 23
(920 Views)

@CoastalMaineBird wrote:

there is a 1 second wait between the execution of the first and last state so I am not sure what is unexpected exactly

 

Run it as is, and you see a 1000 mSec difference in the displays.

 

Convert the FLAT sequence into a STACKED sequence and notice the CHANGE in behavior.

 

THAT is what is unexpected.


I'm not saying it was the right way to do things, but I do know that this behavior was intende by NI.  I think the main case was if somebody had an output tunnel from frame X being wired to an input tunnel in frame Z.  So each frame of a flat sequence structure is handled as a seperate structure.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 15 of 23
(913 Views)

@aputman wrote:

 

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.


That's not correct.  The first frame needs to complete before the second will begin.  It's just that the first will start, as long as all its inputs are avaiable, even if the inputs to the second frame aren't.

Jim
You're entirely bonkers. But I'll tell you a secret. All the best people are. ~ Alice
For he does not know what will happen; So who can tell him when it will occur? Eccl. 8:7

0 Kudos
Message 16 of 23
(902 Views)

@jcarmody wrote:

@aputman wrote:

 

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.


That's not correct.  The first frame needs to complete before the second will begin.  It's just that the first will start, as long as all its inputs are avaiable, even if the inputs to the second frame aren't.


Yeah i figured that out after i reread the help.  I was reading it incorrectly.

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 17 of 23
(895 Views)

Thank you for this vi. It was very helpful to me.

My experience with LabView help is that it needs a lot of searching to find more than very basic tutorials and good explained examples.

 

Martin

0 Kudos
Message 18 of 23
(846 Views)

Don't forget to mark the thread as solved.

0 Kudos
Message 19 of 23
(819 Views)

@CoastalMaineBird wrote:

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.

 

No, you wouldn't. There is no other structure where one output of the structure is available  a whole second before another output of the same structure.

 

Not one.

 

 


You're viewing the structure as a single entity.  Why?  That goes against the entire purpose of breaking things into frames to begin with.  It'd be crazy for it to act as you suggest.  Once the frame is over, it's over.  Adding frames is adding a new structure.  Visually, it's easier to see it as the "single" structure.  But, conceptually it's easy to see they're different structures.  You want to harp on the "not one" idea.  How many other structures can you simply add another piece to at the end?  Can you do that with a while loop?  Can you do it with a for loop?  Does the event structure magically add another frame?  No, not one.  The structure with the FSS is the frame.  The output isn't available until the frame completes.  This matches everything else you've seen.  As much as you're a fan of these structures, shouldn't you take the time to understand what exactly it is they're doing?

Message 20 of 23
(791 Views)