shift register in sequence structure

[psychomanu]

I would love to see a shift register in a sequence structure, to propagate an error cluster for example. Now you need sequence locals for each step, and if you need to insert a step later on you need to rewire things. I use local variables to propagate the error cluster, but that's 'bad practice'.

Not so with this type of structure (this was made with Paint, just not to confuse anyone, it does not exist in LabView as far as I know):

Looking forward to reactions,

Manu

[shoneill]

If you can wire up things with the error terminal, you shouldn't be using stacked sequence structures.

If you MUST use a sequence structure, use a flat one.

Shane.

[psychomanu]

You're absolutely right.

But the very reason a stacked sequence exists is because a flat one sometimes takes too much space, and then a shift register would come in handy.

Thanks anyway,

Manu

[shoneill]

QUOTE (psychomanu @ Apr 3 2009, 12:12 PM)

You're absolutely right.

But the very reason a stacked sequence exists is because a flat one sometimes takes too much space, and then a shift register would come in handy.

Thanks anyway,

Manu

Just wanted to make sure you're aware of the pros and cons of stacked sequences.

I have also thought about this kind of thing in the past, but I generally avoid stacked sequences like the pest, so in the end, I just couldn't bother about it.

You could use a FOR-Loop with a case structure inside (Wired to the i terminal) as a stacked sequence replacement. You can then have shift registers.

Shane.

[psychomanu]

That's a good workaround, thanks.

[Cat]

QUOTE (psychomanu @ Apr 3 2009, 05:54 AM)

I would love to see a shift register in a sequence structure

All the Bad Things about stacked sequence structures aside... philosphically, I agree with this suggestion. I am very anal retentive about inputs coming in on the left side of a subvi and outputs going out the right side. This means when I use a sequence local as an input, I have to drag the wire all the way from the right side of the sequence and make a couple turns before I can put it into a lefthand terminal on a vi (or vice-versa if I've put the sequence local on the left side of the sequence). This definitely contributes to spaghetti looking code. Don't tell anyone, but I have been know to create a local variable for a later sequence instead, just to improve readability. A shift register-like terminal would solve this problem.

[Aristos Queue]

This suggestion has been explicitly rejected by LV R&D multiple times over the years because it would contribute to the ease-of-use of stacked sequence structures, thereby encouraging their use.

QUOTE

You're absolutely right.

But the very reason a stacked sequence exists is because a flat one sometimes takes too much space, and then a shift register would come in handy.

No -- the reason stacked sequence structures exist is that we didn't have flat sequence structures at the dawn of LV and taking them away now would upset people.

[PaulG.]

QUOTE (Cat @ Apr 3 2009, 08:13 AM)

All the Bad Things about stacked sequence structures aside... philosphically, I agree with this suggestion. I am very anal retentive about inputs coming in on the left side of a subvi and outputs going out the right side. This means when I use a sequence local as an input, I have to drag the wire all the way from the right side of the sequence and make a couple turns before I can put it into a lefthand terminal on a vi (or vice-versa if I've put the sequence local on the left side of the sequence). This definitely contributes to spaghetti looking code. Don't tell anyone, but I have been know to create a local variable for a later sequence instead, just to improve readability. A shift register-like terminal would solve this problem.

If I need the functionality of a stacked sequence I'll use a queued message handler. A single frame of a sequence structure is quite handy sometimes to ensure data flow, but I can't imagine why anyone would want to use a stacked. They are inflexible and ugly.

http://lavag.org/old_files/monthly_04_2009/post-3786-1238764335.png' target="_blank">

[ASTDan]

This is my take on a sequence structure.

I only use this when creating reports when I need to do things sequentially and I need a way to easily add cases. I am still playing around with it

[Cat]

QUOTE (PaulG. @ Apr 3 2009, 09:16 AM)

If I need the functionality of a stacked sequence I'll use a queued message handler. A single frame of a sequence structure is quite handy sometimes to ensure data flow, but I can't imagine why anyone would want to use a stacked. They are inflexible and ugly.

Wow, I think I'm having a flashback. I'm pretty sure I was involved in this same conversation 15 years or so ago.

By far my major use of stacked sequences is to put setup code in seq#0, the main program in seq#1, and cleanup code in seq#2.

Along with wiring guidelines I am also anal retentive about making my code all fit on 1 screen (not always easy with my standard 1024x768 laptop screen). Sometimes that becomes problematic -- say for instance I'm initializing all the values in a 50 element structure I'll be using for a state machine. There's no nice way to pass all that into a subvi. So it might get its own sequence. I'd much rather have to click once to move to the next sequence than scroll all over the place to see what comes next.

So there you go. Reason(s) why someone might use a stacked sequence.

[shoneill]

QUOTE (Aristos Queue @ Apr 3 2009, 01:35 PM)

This suggestion has been explicitly rejected by LV R&D multiple times over the years because it would contribute to the ease-of-use of stacked sequence structures, thereby encouraging their use.

No -- the reason stacked sequence structures exist is that we didn't have flat sequence structures at the dawn of LV and taking them away now would upset people.

So why not take it off the main structure palette. Put it somewhere obscure so that people will switch due to the "annoyance" factor. Like a dedicated "deprecated" palette or something.

Shane.

[Michael Aivaliotis]

QUOTE (psychomanu @ Apr 3 2009, 02:54 AM)

...Now you need sequence locals for each step, and if you need to insert a step later on you need to rewire things.

Exactly. This is why you don't use sequence structures.

QUOTE (psychomanu @ Apr 3 2009, 02:54 AM)

I use local variables to propagate the error cluster, but that's 'bad practice'.

No, 'bad paractice' is using sequence structures. Using local variables on top of that just makes things worse.

QUOTE (psychomanu @ Apr 3 2009, 02:54 AM)

Looking forward to reactions,

Manu

It seems, from your example, that you already have error clusters going into and out of your VI. What is the point of the sequence structure? Just daisy-chain all your subVIs together. I'm not sure if this design is intended as a quick prototype or if this method is used in real working code. If it's real code, please consider changing your design to use a http://wiki.lavag.org/State_Machine' rel='nofollow' target="_blank">state-machine.

[psychomanu]

QUOTE (Michael Aivaliotis @ Apr 3 2009, 05:11 PM)

I'm not sure if this design is intended as a quick prototype or if this method is used in real working code. If it's real code, please consider changing your design to use a state-machine.

The design I included was just to illustrate the principle. I'm aware of how to use error terminals to control dataflow. I disagree that stacked sequences are per definition bad practice. There are situations where I prefer a stacked sequence over a bunch of daisy-chained subVI's, especially when dealing with code that I prefer not to be in subVI's, like property nodes of front panel items or so.

QUOTE (psychomanu @ Apr 3 2009, 11:54 AM)

Now you need sequence locals for each step, and if you need to insert a step later on you need to rewire things. I use local variables to propagate the error cluster, but that's 'bad practice'.

QUOTE (Michael Aivaliotis @ Apr 3 2009, 05:11 PM)

Exactly. This is why you don't use sequence structures.

With my suggestion this argument against stacked sequences no longer applies, making them perfectly good practice, just like any other stacked structure like a case structure or event structure. Anyway, it was not my intention to start endless discussions, I guess this comes down to personal taste. Thanks for all reactions.

[shoneill]

QUOTE (psychomanu @ Apr 3 2009, 04:39 PM)

I disagree that stacked sequences are per definition bad practice. There are situations where I prefer a stacked sequence over a bunch of daisy-chained subVI's, especially when dealing with code that I prefer not to be in subVI's, like property nodes of front panel items or so.

Your preferences are not the sole deciding factor in whether something is good or bad practice.

Stacked sequences are bad.

Shane.

[Cat]

QUOTE (shoneill @ Apr 3 2009, 11:56 AM)

Stacked sequences are bad.

Don't hold back Shane. Tell us what you *really* think.

I'm of the "Guns don't kill people; People kill people." philosophy. Or more to the point: it's really easy to use stacked sequences badly, but that doesn't mean they can't serve a useful purpose.

I haven't seen any actual technical reasons posted not to use stacked sequences (if you have a clue what you're doing). Both stacked sequences and state machines (as well as event structures) hide code, so that's not an issue. I'm also not sure what the point is of using a state machine to replace a sequence when the same states always get executed in the same order. That seems like extra code to do the same thing.

An aside: It suddenly struck me this morning -- of the 20 or so top level vis that are in my Big Project, there's only one vi that I haven't used my usual setup/main/cleanup sequence, keep it all to one screen design. And that's the vi that's blowing up on me after running for 8 hours. Hmm....

[Neville D]

QUOTE (Cat @ Apr 3 2009, 07:00 AM)

Wow, I think I'm having a flashback. I'm pretty sure I was involved in this same conversation 15 years or so ago.

By far my major use of stacked sequences is to put setup code in seq#0, the main program in seq#1, and cleanup code in seq#2.

Along with wiring guidelines I am also anal retentive about making my code all fit on 1 screen (not always easy with my standard 1024x768 laptop screen). Sometimes that becomes problematic -- say for instance I'm initializing all the values in a 50 element structure I'll be using for a state machine. There's no nice way to pass all that into a subvi. So it might get its own sequence. I'd much rather have to click once to move to the next sequence than scroll all over the place to see what comes next.

You could make an Init SubVI with error clusters and then wire this up to the next Main program VI and then a Cleanup VI with error chaining.. no need for sequences at all.

Or you could make a nice neat state machine with 3 states: Init, Main, End. It would all fit nicely onto your laptop screen. Seriously, once you get out of the "bad habit" of using sequences, you never go back.

I seldom if ever use a sequence structure and in the few cases I do, its usually a single frame to force data flow.

N.

[jcarmody]

QUOTE (Cat @ Apr 3 2009, 12:22 PM)

Don't hold back Shane. Tell us what you *really* think.

I'm of the "Guns don't kill people; People kill people."

The shirt from Happy Gilmore, I couldn't hurt a fly.

[Cat]

QUOTE (Neville D @ Apr 3 2009, 12:42 PM)

Or you could make a nice neat state machine with 3 states: Init, Main, End. It would all fit nicely onto your laptop screen. Seriously, once you get out of the "bad habit" of using sequences, you never go back.

All right! I give! I'm not too old to change my paradigm and think about using a state machine for static states.

I suppose it would be useful if there's a lot of info that needs to be passed between the states/sequences. Often, tho, that's not the case (just starting up instruments or dynamically calling vis, for example), and I really think a sequence might be simpler.

[Mark Yedinak]

QUOTE (Cat @ Apr 3 2009, 12:11 PM)

All right! I give! I'm not too old to change my paradigm and think about using a state machine for static states.

I suppose it would be useful if there's a lot of info that needs to be passed between the states/sequences. Often, tho, that's not the case (just starting up instruments or dynamically calling vis, for example), and I really think a sequence might be simpler.

The beauty of a state machine is that it is flexible and can be easily modified such as adding new states or reordering things if necessary. It also allows you to jump to a specific state such as an error handler. A sequence frame, rather flat or stacked (and stacked is definitely the nastier of the two) will force the execution, all frames MUST and WILL be executed, and they are very difficult to add new frames if the need arises. I am in the same camp as Neville that I rarely use sequence frames and when I do they tend to be the single frame variety to force data flow. I used to do the same thing as you with the init, main and exit frame sequence structure and after a while found it was difficult to extend when required. Now I prefer to use state machines and of course putting more things into subVIs.

[ASTDan]

QUOTE (Cat @ Apr 3 2009, 12:22 PM)

I'm also not sure what the point is of using a state machine to replace a sequence when the same states always get executed in the same order. That seems like extra code to do the same thing.

I find it is easier to add cases, and you have the advantage of the shift register to store you Report reference and error cluster. I only use this for generating reports, because it is a very sequential thing and sometimes stringing all the functions in a row can get HUGE. It is just a way to keep a report generating sequence from taking up a lot of real estate.

[Cat]

QUOTE (Mark Yedinak @ Apr 3 2009, 01:28 PM)

The beauty of a state machine is that it is flexible and can be easily modified such as adding new states or reordering things if necessary. It also allows you to jump to a specific state such as an error handler. A sequence frame, rather flat or stacked (and stacked is definitely the nastier of the two) will force the execution, all frames MUST and WILL be executed, and they are very difficult to add new frames if the need arises.

Don't get me wrong -- I love state machines and use them all over the place. I just never made the leap into using it to make more simplified transitions between parts of my code that *always* go step1->2->3->etc.

I'm giving it a whirl right now with my big, messy, 3x4 screens, dies-after-8 hours vi. If I can make it work there, I can do it anywhere.

[crelf]

I can imagine that, if shift registers were added to sequence structures, it'd be confusing when working with unintialized shift registers.

[shoneill]

QUOTE (Cat @ Apr 3 2009, 05:22 PM)

I haven't seen any actual technical reasons posted not to use stacked sequences (if you have a clue what you're doing). Both stacked sequences and state machines (as well as event structures) hide code, so that's not an issue. I'm also not sure what the point is of using a state machine to replace a sequence when the same states always get executed in the same order. That seems like extra code to do the same thing.

A stacked sequence, in contrast to a state machine or an event structure does not contain frames which MAY be executed. They will ALL be executed. An event structure groups many different possible execution units together, one of which will execute at a time. Here it makes sense to hide the other possible execution units. Ditto with a state machine. Granted a state machine CAN execute from 0 to n like a stacked sequence, but it doesn't HAVE to be that way.

So that's the difference for me. A stacked sequence structure adds no extra functionality over a flat sequence and while it's at it hides code which is a bad thing unless it's necessary.

Shane.

[Anders Björk]

QUOTE (Cat @ Apr 3 2009, 02:13 PM)

All the Bad Things about stacked sequence structures aside... philosphically, I agree with this suggestion. I am very anal retentive about inputs coming in on the left side of a subvi and outputs going out the right side. This means when I use a sequence local as an input, I have to drag the wire all the way from the right side of the sequence and make a couple turns before I can put it into a lefthand terminal on a vi (or vice-versa if I've put the sequence local on the left side of the sequence). This definitely contributes to spaghetti looking code. Don't tell anyone, but I have been know to create a local variable for a later sequence instead, just to improve readability. A shift register-like terminal would solve this problem.

If one chose to use the stacked sequences it is for stepvis math algorithms and using local variables tend to get messy. I think would be very nice with shift registers instead of locals. By the way would feedback node do the work in this case? If so is the case why would not shiftregisters too. So I agree totally the locals contribute to the spagettiness.

Regarding state machine why use something that is more complicated than needed for a specific task, I dont see the rationale for that. That is if the task have predefined steps and well defined steps, that do not change with time.

[PJM_labview]

QUOTE (Cat @ Apr 3 2009, 11:06 AM)

Don't get me wrong -- I love state machines and use them all over the place. I just never made the leap into using it to make more simplified transitions between parts of my code that *always* go step1->2->3->etc.

And the beauty of having it in a frame of the state machine is that the day you need to call that init frame back (when not doing per say an init step [this does occurs on occasion especially for UI stuff]) you can easily do that without creating duplicate code.

PJM