LabVIEW
Remove the stacked sequence structure from LabVIEW.
If you look at old posts and very very old LabVIEW examples and drivers (like LabVIEW 3) you will notice horrible code based on SSS inside SSS inside SSS.
The SSS was the single most abused LabVIEW feature. It's the first thing most LabVIEW beginners turned to when they came from some text programming and wanted to force LabVIEW into submission to do the same sequential logic that text programming so profoundly forced on them.
It can be useful in a few very limited and isolated use cases but that doesn't weight up against the abuse it promoted by the mere existence in the palette. So it got removed from the palette for a good reason and if you really want to use it you can, but if that extra step of right clicking on a FSS is to much, it probably isn't that important of a feature. 
I can't remember when I last used the SSS, I stopped using it as soon as the FSS was available and didn't use it much before that either.
I find that the more sequence locals you use, the more the SSS becomes a hopeless, jumbled mess with backwards running wires, making it hard to read. With almost no extra effort, you can instead create a state machine that does the same exact thing, is neater, and is much more versatile and scalable.
I have to say that I've never even considered using one before.
LOL, I guess it has been a very long time since I last used a SSS, hadn't even noticed it was missing, didn't know the right click on FSS frame trick. As a previous post mentioned, it was in the earliest LabVIEW examples (2.5.2 was my earliest exposure), when even the creators of LabVIEW didn't really know what they had, so many early LabVIEW programmers were exposed bad techniques from the start, particularly those coming from a text based programming world, who hadn't yet wrapped their heads around data flow and making sub-vi's with error in/out to help force data flow. I do occasionally use the FSS, usually a single frame to, as another early post mentioned, force data flow on those legacy primitives, like timers, that don't have error in/out.
Here's a situation where a FSS doesn't work as well as a SSS:
https://forums.ni.com/t5/LabVIEW/Block-Diagram-is-not-working-properly/td-p/3719945
/S
Good thing it's less easily available.
Search LabVIEW like a graph! Well the OP didn't hear of another rule I am pretty strict about:
If the diagram doesn't fit on a screen it is to big and you should start "carefully" (that does explicitly not mean randomly selecting multiple nodes and applying "Create SubVI") creating sub VIs.
@rolfk wrote:
Well the OP didn't hear of another rule I am pretty strict about:
If the diagram doesn't fit on a screen it is to big and you should start "carefully" (that does explicitly not mean randomly selecting multiple nodes and applying "Create SubVI") creating sub VIs.
That's good advice.
I'm not too strict about that myself (also just pretty strict). If code is a sequence I don't mind too much that it is programmed as a sequence. If each step is "singular", creating sub VI's might just obfuscate things. A state machine doesn't help either, it's not a state machine, it's a sequence. It happens with reporting VI's and such. Step 1, Step 2..Step 10 are all stand alone actions, and grouping them in any way would be arbitrary. Guess this situation is why you said "pretty strict", not 100% strict. This is nothing like OP's situation...
In this case, it would easily fit one screen if those careful sub VI's where created, in combination with a few loops and structures.
Fitting the screen is the ideal and should be the goal.
@CoastalMaineBird wrote:
Fitting the screen is the ideal and should be the goal.
Ok, whose screen should I fit it to?
@Blokk wrote:
@CoastalMaineBird wrote:
Fitting the screen is the ideal and should be the goal.
Ok, whose screen should I fit it to?
Mine of course.
I know it spoils the joke, but changes are none of those screens have more pixels then a decent laptop. The pixels are huge, so the screens a huge, the number of pixels is probably not that high.
wiebe@CARYA wrote:
This is nothing like OP's situation...In this case, it would easily fit one screen if those careful sub VI's where created, in combination with a few loops and structures.
Thought this was a post in the other thread. Doesn't make much sense in this one.
EDIT: Never mind. The contexts are mixed anyway.
