LabVIEW Idea Exchange

Hello (again),

Well, this idea has haunted me for a couple of years, and now I think it's time to break it. I feel the For-loop, the While-loop, and the Timed loop are so similar that they are begging for a merger. It would simplify, and with a little thought strengthen, the API, to have a single configurable Loop Structure instead. What's the difference between a While-loop and a For-loop with a conditional terminal anyway? Have you ever wished for iteration timing information being available inside your For-loop (I know I have)? "Oh but those structures have been around forever, we can't touch those"... Well, what happened with the stacked sequence structure? Please read on for a minute or two and tell me if I'm losing my marbles here. And please chip in with your own modifiers, since LabVIEW is growing in (sometimes unnecessary) complexity. Thus:

Instead I propose the Loop Structure which when initially drawn looks like this:

The above is basically a loop running forever (don't worry, you can stop it), but it can be modified to do many many other things, just be patient . One feature of the loop structure is the box in the upper left corner, which is quite similar to what we have in a For-loop today. This will, no matter the configuration of the loop structure, always show the current iteration setting of the structure. By default that is never-ending, but if you drag in a conditinal terminal you change the loop behavior to a While-loop (note that I suggest a simpler way to get to the terminal than via the right-click context menu):

Arrays can be wired to the structure border as usual to give a For-loop like behavior. The count terminal changes from "Inf" to an "N" to indicate that it's a finite albeit at edit-time unknown number of iterations:

You can wire out of the count terminal inside the loop structure as usual to get the count at run-time of course. If the iteration count can be deducted at edit-time a number will appear instead of the "N":

This number is blue to indicate that it is automatically calculated. You can just type in a new number if you wish to run a different number of iterations, in which case all the usual ideas on this Idea Exchange about what should happen to auto-indexed tunnels apply. If you override the count manually the number will be in black text:

You can of course combine different exit conditions, in this case a fixed number of iterations with a conditional terminal wired as well for possible early exit:

The automatically calculated count terminal aids in determining if the loop actually runs the desired number of times:

All the usual stuff about tunnels, shift registers and so on apply to this structure as well, but on top of that it can also be configured as you're only used to within a timed loop. Consider how valuable some of these parameters and settings could be for ordinary loops, for error handling and for timing for instance. But the main feat is that this is still the same loop structure - it will simplify the palette a lot:

And now an additional feature that ties some of the parameters from the timed structure together with ordinary loops: this loop structure is event-enabled! I propose stuff like this (we're only scratching the surface with this image):

It's late where I am now, so I'll stop now, but all of the above makes it extremely easy to do things you simply can't do today - what about a Priority Structure?:

So, is it time to consolidate the ever-evolving loop code of LabVIEW into one structure to rule them all?

Cheers,

Steen

Hi,

I just thought of a small thing when I enabled the Dynamic Event Terminals on an event structure for the zillionth time - why don't they just appear automatically when I wire a compatible wire to the structure border? Like this:

Of course once in a while you don't want to wire to the Dynamic Event Terminal, but instead want that wire to tunnel through the structure border, but a dab on the CTRL or ESC key could make the Dynamic Event Terminal "suggestion" disappear.

Cheers,

Steen

If you right click on an array wire and choose "insert - array palette - inert into array" you geht this:

It would be better if this happens:

We I love the idea of the new cluster constants. I have found thought if I need to edit these constants to change something It opens the control back to full size. This really defeats the purpose of these space saving features. We need to be able to double click these constants and have them open in a new window so that my block diagram size does not change

If my diagram gets this big if I need to change a true or false state every time I need to change it what good is the nice new icon or constant.

Just a thought.

Must have been discussed a zillion times, but just in case, there it goes:

what's wrong with this picture?

apparently nothing. If I grab the function and move it:

Note that LV must have "computed" something here to reroute the wires, etc.

But wait, what happens if I grab the wire and move it?

Oops! I did not connect the output of the function to the indicator. Instead, I inadvertently connected the input.

Needless to say, this is a F-ing nightmare to debug... unless you think of verifying that the value before the function and after the function actually gets incremented. Which you will, eventually, but not until after having wasted a lot of time thinking of all other possibilities elsewhere in the code.

Bottom line (this is only an example I just encountered for the umpteenth time a minute ago), LV does not provide much in terms of warning for this kind of potentially very damaging error. This is very much related to the discussion I started here with very limited success (man, am I an upbeat person!). 

Suggestion: not only allow to define VI outputs as REQUIRED but also add warnings when a function that has its only or most important output(s) unconnected.

And if not everybody is interested in this kind of sanity check (I am talking about functions), you could offer this "warning" as an option (in a warning definition panel in the Preferences).

When you have copied an row or column of the same data type from Excel, it would be cool if you could click on the desired LabVIEW array cell to paste it into LabVIEW arrays, either on the front panel or Block Diagram.  Nice to have would being able to do it for 2D arrays.

Carsten