Left to Right Process Flow for Converstions from Flat to Stacked Sequences

[Ashley_Bryant]

There are times when the use of Flat and stacked sequences are essential, especially if long sequences of LabVIEW VIs have to be connected together and sequenced at the right time, such as for DAQmx communications. At the moment, if one write's a Flat Sequence and then converts it to a Stacked Sequence, the left to right process flow does not remain in the "read left to right" mode, but gets all muddled, making the Stacked Sequence diagrams messy and muddled. If this "left to right" process flow could be carried across from Flat Sequences to Stacked Sequences, it would make a huge difference to the ability to see clearly the process flow, reduce the size of the block diagrams on the screen and improve the usability of LabVIEW programming.

The first diagram below illustrates a block diagram outlining in a simplified way, the need for "tight control" of the timing of DAQmx vi calls, using a Flat Sequence with the second diagram illustrating the spagetti process flow connectors following a conversion from a Flat Sequence to a Stacked Sequence.

[AristosQueue (NI)]

Judicious use of the Merge Error node would eliminate your sequence structures entirely in the pictures shown.

[F._Schubert]

No vote because I think this isn't a good programming style.

The use of stacked sequences shoul really be marked as legacy and no effort taken onto them exept to hide them way down the palettes.

Considering your example.

If you have a dependency of the channels, you actually need to merge the errors after each step.

If it's multiple DUT's (so no dependency), then this code needs to be architected in a very diffrent way.

If it's a single DUT, you then better form SubVIs for each step (Init equipement, run test, clear), where the chennnels are bundled to a cluster.

Felix

[Ashley_Bryant]

You are missing the key point. It just so happens that I have used an example that has error wires after each step, that was a mistake on my part! Forget about the errors and think about the problem from a more generic / generalised perspective, then you might see the merit of the proposal.

With regards to your comments that Flat or Stacked Sequences are legacy, the problem is that when developing programmes that require long DAQmx vi chains or when using ActiveX vi's for example (and I am sure that there are many other examples that are available), the chain of vi's can become very long. Structuring these vi's in such a way that they are modular and readable on a standard computer screen is a real challenge, hence the need for Stacked Sequences. The theory is all very well and academic, but in practise it does not always stack up.

[Mark_Yedinak]

No, I believe you are missing the point. Felix is quite correct that the use of sequence structures is not a good idea. There are lots of discussions in the forums which cover this. In a nutshell though I would strongly recommend you consider using a state machine architecture. It is much more powerful as well as easier to maintain and enhance. In addition, you may want to consider creating and using more subVIs. Good use of subVIs helps to minimize your block diagram size as well as makes it easier to reuse code.

Your statement that there aren't better ways to accomplish what you are suggesting doesn't "stack up". There are only two ways I have used sequence structures in very long time. The first is to impart dat flow where one does not exist. In almost all cases a single sequence frames wraps around one or two VIs on the block diagram. The second way which is only rarely used is to time specific pieces of code. A three frame flat sequence is used. The first frame gets the start time, the second has the code I want to time and the third gets the end time.

Better use of subVIs and other architectures (state machines, producer/consumer, event structures, etc.)

[Mark_Yedinak]

Last comment was sent before it was finsihed.

Better use of subVIs and other architectures (state machines, producer/consumer, event structures, LVOOP, etc.) will help make your coding easier, more maintainable, more readable, and robust than relying on bad coding techniques. Take some time to learn these techniques and you will find you end up with better code.

[Darren]

Any idea that has received less than 3 kudos within 3 years after posting will be automatically declined.