Snelephant

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?

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

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?

Perfect! The key here is the 'Call Chain' function, which I had not been aware of. Thanks a lot. Snelephant

A.vi calls B.vi. Is there a way to acquire the path to A.vi from within B.vi without explicitly supplying this to B.vi?

Thank you for the helpful explanation. When the strictly typed reference was connected to a weakly typed sub VI, a red dot appeared at the connection. I interpreted this to be a class conflict, but perhaps the dot is there just to indicate that inputs will be "upclassed" as necessary, according to your explanation.

The output of a tree control reference defaults to a strictly typed refnum. (The reference was created by right-clicking the tree control in the front panel->create->reference.) Is there a way to convert this output to weakly typed? For most refnums that appear in the front panel there is an option to switch between strict and weak types by deselecting "Include data type." But this method does not seem to be available for the VI server reference. How does one specify a weakly typed output from a tree control reference?