shift register in sequence structure

[Mark Yedinak]

QUOTE (shoneill @ Apr 6 2009, 01:37 PM)

Would it be possible to write a Stacked Sequence Structure to State Machine converter using scripting?

Shane.

It seems like it would be possible however I will confess to having very little knowledge of VI scripting. I have never really played around with it.

[crelf]

QUOTE (shoneill @ Apr 6 2009, 02:37 PM)

Would it be possible to write a Stacked Sequence Structure to State Machine converter using scripting?

Absolutely - it wouldn't be too difficult to implement.

[shoneill]

QUOTE (crelf @ Apr 6 2009, 09:05 PM)

Absolutely - it wouldn't be too difficult to implement.

I've never done scripting in LV, but it seemed relatively straight forward in my mind. But that's nothing, lots of things look really different in my mind....

Shane.

[crelf]

QUOTE (shoneill @ Apr 6 2009, 05:44 PM)

I've never done scripting in LV, but it seemed relatively straight forward in my mind.

You'd need to know which sequence structure you wanted to convert into a state machine - probably by label - and it should be okay from there (it wouldn't necessarily be easy, but it'd be straightforward - just copy the code from each sequence structure pane in oreder into a case, wire up shift registers where tunnels are wired between panes and voila!

It'd be pretty neat to be able to get into the hooks to be able to add "Convert to State Machine" when the user right-clicks on the sequence structure border

[Rolf Kalbermatter]

QUOTE (crelf @ Apr 6 2009, 05:11 PM)

You'd need to know which sequence structure you wanted to convert into a state machine - probably by label - and it should be okay from there (it wouldn't necessarily be easy, but it'd be straightforward - just copy the code from each sequence structure pane in oreder into a case, wire up shift registers where tunnels are wired between panes and voila!

It'd be pretty neat to be able to get into the hooks to be able to add "Convert to State Machine" when the user right-clicks on the sequence structure border

Ah but last time I checked the shortcut menus of build-in LabVIEW objects seemed still to be straight coded up in the LabVIEW C source code and not some hidden LabVIEW VI somewhere. So that seems like a problem to me :headbang:

Rolf Kalbermatter

[ShaunR]

QUOTE (crelf @ Apr 6 2009, 09:05 PM)

Absolutely - it wouldn't be too difficult to implement.

Go on then

Here's a more up to date conundrum in a similar vein (everyone says sequence structure are bad...but everyone uses them...even NI)

Of the following two methods to build a vi global. Which is better?

http://lavag.org/old_files/monthly_04_2009/post-15232-1239919373.jpg' target="_blank">

[crelf]

QUOTE (ShaunR @ Apr 16 2009, 06:05 PM)

Go on then

No worries - who should I send my rate schedule to?

[ShaunR]

QUOTE (crelf @ Apr 17 2009, 06:16 AM)

No worries - who should I send my rate schedule to?

The same people who pay you for the time you spend posting on this forum

[Yair]

Personally, I dislike the backwards facing SR. I guess I feel that they just look wrong. We had a discussion here and here are some alternatives I posted there. Maybe you should add your thoughts there.

You should note that the local variable method does actually work (although I never actually used it) and has the advantage of providing a name so you have some documentation. NI could technically build something like this which would have a name without having an extra memory allocation and a node.

[crelf]

QUOTE (ShaunR @ Apr 17 2009, 03:20 AM)

The same people who pay you for the time you spend posting on this forum

Touche

[Snelephant]

Pardon my resurrecting this thread, but perhaps someone can help me better understand the discussion.

I found this thread having encountered the same issue as the original poster. My VI manipulates several variables over a sequence of steps. Dataflow can be enforced by wiring everything on the block diagram directly, but this quickly becomes a maze of wires. Daisy chaining subVIs cleans up this mess, but also creates subVI's buried several levels deep. Many of these buried subVIs by necessity transport variables that are not used in the subVI. This too is not ideal form.

A stacked sequence seemed like a logical solution. Dataflow is enforced, everything remains on the top level of the block diagram, and there is no tangle of wires or a 20,000 pixel wide flat sequence. Then I stumbled on to this thread and learned that stacked sequences are evil, stacked sequences using local variables are arch-evil, and that real pros do everything using functional globals.

I like state machines as much as the next guy, but can someone clarify to me the functional dangers of using stacked sequences? Stacked sequences are single, fundamental Labview structures, are documented in the help, they are easy to read, and their purpose is plain and obvious. Functional globals are contrived from a case structure, a while loop, and shift registers. Upon first seeing a functional global, it is not readily apparent what it is or what it does. Stacked sequences and queued state machines seem to do the same thing, but stacked sequences seem to be the simpler implementation in Labview. Why are stacked sequences shunned?

[jgcode]

Pardon my resurrecting this thread, but perhaps someone can help me better understand the discussion.

I found this thread having encountered the same issue as the original poster. My VI manipulates several variables over a sequence of steps. Dataflow can be enforced by wiring everything on the block diagram directly, but this quickly becomes a maze of wires. Daisy chaining subVIs cleans up this mess, but also creates subVI's buried several levels deep. Many of these buried subVIs by necessity transport variables that are not used in the subVI. This too is not ideal form.

A stacked sequence seemed like a logical solution. Dataflow is enforced, everything remains on the top level of the block diagram, and there is no tangle of wires or a 20,000 pixel wide flat sequence. Then I stumbled on to this thread and learned that stacked sequences are evil, stacked sequences using local variables are arch-evil, and that real pros do everything using functional globals.

I like state machines as much as the next guy, but can someone clarify to me the functional dangers of using stacked sequences? Stacked sequences are single, fundamental Labview structures, are documented in the help, they are easy to read, and their purpose is plain and obvious. Functional globals are contrived from a case structure, a while loop, and shift registers. Upon first seeing a functional global, it is not readily apparent what it is or what it does. Stacked sequences and queued state machines seem to do the same thing, but stacked sequences seem to be the simpler implementation in Labview. Why are stacked sequences shunned?

I am sure this has been debated many a time, here is one link to another discussion

[Snelephant]

Thanks jgcode for the link. Not to belabor the point, but I still haven't found an explanation of the hazard associated with stacked sequences. It is interesting that even in the thread you linked, there are posts claiming that "stacked sequences are bad" but there are no explanations presented for this stance. However, your post offers some compelling observations:

You will find a plethora a reasons on why people consider the use of sequence structures to be bad style e.g:

• Cannot change execution order without cutting and pasting code
• Forced to wired from right to left when passing data between frames due to the use of sequence locals
• Cannot run the same frame twice
• Have to run the entire sequence from start to end - cannot conditionally abort half way through etc...
• Cases are hidden

These are all valid points, but do they negate that sequence structures may still be an appropriate construct in certain programming scenarios? Consider a set of operations that must be performed in a known order. This sequence is written in stone, has always been thus and will always be thus. You do not want to alter it by accident, and you want anyone reading your code to understand that this sequence is not to be tampered with. One example may be a set of instructions for allocating and deallocating memory. In such a case, a sequence structure is a clear signal to enforce the execution order.

• Cannot change execution order without cutting and pasting code

Good. We want to discourage casual modification.

• Have to run the entire sequence from start to end - cannot conditionally abort half way through etc...

Again, enforcing this restriction may be by design. For example, Aborting a memory operation mid sequence could lead to memory leaks.

• Cannot run the same frame twice

This is part of the definition of a sequence.

• Cases are hidden

Cases are hidden in most corners of Labview. Case structures, subVI's, etc. They are simple to inspect.

• Forced to wired from right to left when passing data between frames due to the use of sequence locals

This is indeed the most compelling reason to avoid stacked sequences! Definitely frustrating. But this is not due to an inherent limitation of sequences. It has been implied that it is instead the result of a conscious decision by NI to not implement sequence locals in a friendly manner. What gives? This was the original poster's point and also my motivation.

[jgcode]

Thanks jgcode for the link. Not to belabor the point, but I still haven't found an explanation of the hazard associated with stacked sequences.

No probs.

Well I think you have, as that topic is a fairly good summary of the advantages/disadvantages of using Sequence Structures.

And I think you can bump heads on this all day/week/year with anyone.

If you like using them, then by all means use them.

Below is my take on the subject.

This sequence is written in stone, has always been thus and will always be thus.

The only thing that is guaranteed in software development is CHANGE.

Whilst your saying it is "set in stone" - that may be the case today, but will it be so in a month/ in a year etc...

I have found that you cannot always predict the future.

Therefore, I prefer I more flexible approach

Sequence Structure do not provide me with that.

You do not want to alter it by accident, and you want anyone reading your code to understand that this sequence is not to be tampered with.

One example may be a set of instructions for allocating and deallocating memory. In such a case, a sequence structure is a clear signal to enforce the execution order.

• Cannot change execution order without cutting and pasting code

Good. We want to discourage casual modification.

You should be able to do this with good documentation.
Relying on a developer to "read you code" and to make that assumption, is probably not the best idea (and not the fastest/easiest way to come up with that conclusion)
Also, if you have problems with people editing something accidentally these could be avoided using a Source Code Control system.

• Have to run the entire sequence from start to end - cannot conditionally abort half way through etc...

Again, enforcing this restriction may be by design. For example, Aborting a memory operation mid sequence could lead to memory leaks.

Well that one comes down to good programming.

If your sequence is 100 cases long and you need to stop mid way through, you can't. You are stuck having to run the other 50.

That is inflexible to me.

Whichever design you choose, if you do add in an abort feature/function, you should do so cleanly, and tidy up your references etc.. to avoid leaks.

Not doing so would be lazy/bad programming.

• Cannot run the same frame twice

This is part of the definition of a sequence.

No by definition a sequence is a succession of something.
Not being able to run the same frame twice is not good for flexible/reusable code.

• Cases are hidden

Cases are hidden in most corners of Labview. Case structures, subVI's, etc. They are simple to inspect.

Yes, but in the argument of Flat vs Stacked Sequence Structures, Flat would allow more code to be viewable.

• Forced to wired from right to left when passing data between frames due to the use of sequence locals

This is indeed the most compelling reason to avoid stacked sequences! Definitely frustrating. But this is not due to an inherent limitation of sequences. It has been implied that it is instead the result of a conscious decision by NI to not implement sequence locals in a friendly manner. What gives? This was the original poster's point and also my motivation.

I am glad they did this. Sequence Structures are bad

[Cat]

You've stepped into a religious war.

I think that (as usual) AQ has the best response to this issue. As he stated in the thread you were pointed to:

"Sequence structures are to LabVIEW what sentence fragments are to English. Both are so problematic that we have to teach newbies "never use these" and then later we can say, "ok, now you can use them because you now understand how they work with relation to the rest of the grammer." Sequence structures have value, but new users to LV tend to over use them gratuitously and thus end up killing the performance of their code. Similar with sentence fragments. ;-) "

Bottom line, only use a sequence structure if it's the *best* way to get the job done. Not just when it's the easiest way. A lot of beginning LV programmers don't have enough experience to know the difference.

(Hmm, I think I used a sentence fragment in the above paragraph. )

[shoneill]

I used a stacked sequence recently and the next day I got kidney stones!

Coincidence? Almost certainly.

Do you want kidney stones? Didn't think so.

I rest my case.

Flawless logic.

Shane

PS This REALLY happened and kidney stones are one of the very few things WORSE than stacked sequence structures.....

[Snelephant]

"Sequence structures are to LabVIEW what sentence fragments are to English. Both are so problematic that we have to teach newbies "never use these" and then later we can say, "ok, now you can use them because you now understand how they work with relation to the rest of the grammer." Sequence structures have value, but new users to LV tend to over use them gratuitously and thus end up killing the performance of their code. Similar with sentence fragments. ;-) "

This is the distinction I was looking for. When used incorrectly, sequence structures can decrease performance. Of course this applies to any programming structure, but sequence structures in particular are prone to abuse from inexperienced LV users.

The hatred of sequence structures was so prevalent as to suggest they were inherently buggy or had been implemented incorrectly by LV. I was worried that I had unknowingly planted time bombs in my VIs. I see now that this largely boils down to a question of style and restraint. In fact, I agree state machines are superior methods for controlling program flow. Has LV ever considered implementing a state machine structure for the structures palette?

[Francois Normandin]

Has LV ever considered implementing a state machine structure for the structures palette?

You can do it on your own with templates you've customized for your own particular needs. One known example is the JKI State Machine.

I'm not sure you want to add it to the Structure palette, though it's possible. NI provides such templates in the "New VI Dialog", not as drop-ins VI in the palette. I usually keep my templates in user.lib since it's easily exportable from version to version.

[asbo]

The hatred of sequence structures was so prevalent as to suggest they were inherently buggy or had been implemented incorrectly by LV.

Don't overlook the possibility that it being implemented is what we see as the bug.