From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Is there anything wrong with sequence structures?

cebailey:

> Yes, you can replace a stacked sequence with a state machine. That is not a reason to never use stacked sequences, any more than the fact you might be able to replace a state > machine with a stacked sequence is a reason to never use state machines.

 

Wrong. You can't replace a state machine with a sequence. Only the linear type can be replaced. But what if the customer says, 'I want to have a cancle button and a revert button and the option to skip test step 3 and the option to repeat step 2 after step 6'? Rewrite the program or adapt it?

 

What points most on using a state machin is the following sentence from post one:

> the 2nd page with my main while loop (and within the while loop there will be another stacked sequence with several pages)

 

I really don't care if someone is using a 3 pages sequence with init, go and shutdown code. But then there is a need for some more. and now you have a sequence inside a sequence. And then the next programmer is taking the project and places a while loop and a sequence. And after adding a bunch of greate features and options, someone like me is getting headaches.

And when I showed some fellow developer the concept of a state machine, he just told me the next way: hell-of-greate-stuff. Never happend with any other concept the same way.

I'm willing to discuss any concepts, but a state machine is a must. I'm willing to be called 'state-machine-fundamentalist'.

 

Regarding error wires:

I really have no need of 'sequencing' stuff in my program. They should perform the action they do only when there is no error in the wire (I don't want to wait n times the settling time when I forget to power on the instrument) or should only execute on error (like error logging). Half the code is about error handling, and thats not a LV issue.

 

Ok, it's Sat night and I should go out now.

 

Felix

0 Kudos
Message 11 of 14
(1,093 Views)

We have discussed the disadvantages of stacked sequences many times.

 

So you are basically trying to eliminate horizontal diagram scrolling by flipping through sequence frames. I am not really sure that one is better than the other. Actually, given a choice, I would probably prefer scrolling. 🙂 Scroll left to see the initialization steps, scroll right to see the cleanup code. 😉

 

Normally, the three steps (init, main, cleanup) are probably linked in some way by data dependency, e.g. the error wires. If you now "solve" things with a stacked sequence, you need to break that nice left-to-right flow and pick alternatives. Two typical (misguided) choices:

  1. use sequence locals. while stacked sequences are not very appealing, stacked sequences with sequence locals are the worst, because they makes code completly unreadable.
  2. use local variables or similar gadgets. Again we break dataflow and introduce additional data copies in memory for no good reason.

Stacked sequences date back to the time of 640x480 screen resolutions. They are the dinosaurs of LabVIEW coding. I have never felt the need for stacked sequences. The last time I used one was in LabVIEW 4.0. (I still use flat sequences where appropriate).

 

I would even suggest that NI remove the stacked sequence from the palette (as has happened to many legacy features). 🙂

Message 12 of 14
(1,080 Views)

I personally think that there are places where stacked sequence structures (even with many frames) are relevant. I've done more than one system where there is a lot of code which needs to be performed sequentially. Always. Every single time. No tricks. No "let's do this and then that" or "let's skip this part this time because there's an error". Some of the code could be placed in subVIs or run in a compicated for loop, but the stacked sequence tends to be the simplest and cleanest solution. As mentioned, sequence locals are bad form and it would be nice if sequence structures supported shift registers.

 

That said, SSS can obviously be abused. The points made by the others are certainly relevant in many (if not most) cases, but not always. The trick is knowing the pros and cons and being able to make an informed decision.

 

P.S. I also prefer the dot at wire intersections and feel that these things are usually a matter of taste. Yes, even sequence structures which can affect the architecture of a program. Not every program needs to be scalable and future proof.


___________________
Try to take over the world!
Message 13 of 14
(1,064 Views)

Yay, tst! I agree completely!

 

>...the fact that you might be able to replace a state machine with a stacked sequence...
>Wrong. You can't replace a state machine with a sequence.

 

No, I'm making a different point. Of course you can't replace state machines with sequences in general. I'm saying that if you create a state machine that is so simple it could be replaced with a sequence, the fact you could replace it with one doesn't mean you should.

 

>Your last point is sort of like saying its ok to play russian roulette as long as you don't get shot.

 

But, it IS ok to play Russian Roulette if you don't get shot. The part about getting shot is the only problem.

 

>If you use sequences your code will have complicated wiring and your code will be unreadable - and with this it's not a 1 in 6 chance, its guaranteed.

 

Surely it is possible to use a stacked sequence in a way that does not create complicated wiring and unreadable code, no?

 

Message 14 of 14
(1,046 Views)