LabVIEW
Use of sub-VIs to reduce block diagram size in top level VI
@NeilR wrote:
I thought the stacked sequence comment would provoke an interesting response !
What I would say is that I pass no wires to or from any of the stacked frames. I get that.
It's simply a "fixed state machine" if you like that applies to pretty much all situations in the top-level VI.
Generally in frame 1 I do things like Reinit All to Default, hide the front panel - resize it to largest decoration (thanks OpenG !) and then fade in using graduated transparency ... mmmm nice ... plus store things like Tab terminals and the like.Frame 2 is where the magic happens.
... and usually contains a state machine or event structure.
Frame 3 is usually no more than a front panel fade out and environment dependent shutdown.
I totally agree that the use of stacked frames can extend a wiring nightmare from 2 dimensions to 3. I would say though that judicious use of stacks by experienced developers can keep things very tidy, but if you're uncomfortable then stick to state machines.
One of the criticisms of stacked sequence is that it hides parts of code. You need to scroll through each sequence to see what is going on.
Won't it make the code more readable to do initialisation - processing - shutdown using Dataflow rather than an enforced sequence?
@t.d.b wrote:
@NeilR wrote:
I thought the stacked sequence comment would provoke an interesting response !
What I would say is that I pass no wires to or from any of the stacked frames. I get that.
It's simply a "fixed state machine" if you like that applies to pretty much all situations in the top-level VI.
Generally in frame 1 I do things like Reinit All to Default, hide the front panel - resize it to largest decoration (thanks OpenG !) and then fade in using graduated transparency ... mmmm nice ... plus store things like Tab terminals and the like.Frame 2 is where the magic happens.
Frame 3 is usually no more than a front panel fade out and environment dependent shutdown.
I totally agree that the use of stacked frames can extend a wiring nightmare from 2 dimensions to 3. I would say though that judicious use of stacks by experienced developers can keep things very tidy, but if you're uncomfortable then stick to state machines.One of the criticisms of stacked sequence is that it hides parts of code. You need to scroll through each sequence to see what is going on.
Won't it make the code more readable to do initialisation - processing - shutdown using Dataflow rather than an enforced sequence?
Not quite sure what you mean by 'hides parts of code'?
The situation is identical to case statements and event structures in that there are 'frames' in the Z plane.
You don't need to 'scroll through' the frames in a stacked sequence anyway, they are all available from the dropdown at top-centre of the structure, just like events and cases. 
@rolfk wrote:
@Yamaeda wrote:
You can do some tests if you're really interested. A subVI call adds a few nanoseconds, but that can be removed if you make the function/SubVI Inline. Usually that's negligable, but as Always there's some cases in which those few extra ns's is what's needed.
Knowing about it though, can be quite good, as the suggestion then becomes to have a subVI that accepts an Array and does the looping internally instead of having a function inside a loop … i'll have to do some test to try out my own hypothesis. 🙂
Unless you have a subVI that contains a minimum amount of code inside and you call it in a tight loop billions of times, you will be hard pressured to measure any increase in execution time for that subVI compared to having its code executed directly in the diagram. And for those cases you have the inline option.
If your subVI contains anything but non trivial code, its own execution time will be usually magnitudes higher than the overhead of calling it as subVI.
Yes. Quite right. But sometimes subVI's are in the ballpark of '+1' in functionality, and in that case it should be noticable with a 1E9 element array ... maybe.
/Y
I think the thing that most annoys me about the SSS is that the frames are labeled as numbers, which is terrible for self-documenting code. Not much fun if you have more than a few frames. The thing that annoys me almost as much is that programmers that use the SSS are usually in love with it and you find nested stacked sequences. 😉
Regarding the original topic:
If you were writing C code, would you put everything in main() or would you rather have functions to call?
