Jump to content

shift register in sequence structure


Recommended Posts

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):

shiftregister3.png

Looking forward to reactions,

Manu

Link to post
Share on other sites
  • Replies 68
  • Created
  • Last Reply

Top Posters In This Topic

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

post-8614-1238766038.jpg?width=400

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

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)

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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....

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

guns-shirt.jpg

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.