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

Here's a dumb mistake I think many of us can relate to:

It would be really nice if the VI were just broken in this situation. But I can understand why it's not necessarily simple to mark node *outputs* as required.

But maybe there could be a way for the editor to *hint* that there is a problem here. Maybe the bundle nodes could change color when the output terminal is wired, so you could get a little more obvious feedback if you screwed up like this.  The same could go for any other primitives that have a "for type" input (e.g. unflatten from string, variant to data, to more specific class, etc).

Granted, VI Analyzer could report bugs like this, but having a little more immediate feedback would probably be a big win.

(Let me know if this should be cross-posted to the NXG idea exchange, too).

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

I'm a great advocate of commenting code, but with the graphical nature of Labview, you need space on your block diagram to add in a post-it giving your comments. That's great if your block diagram is nice and spread out, but (perhaps due to poor planning/programming) i'm often finding myself getting limited on space. Adding comment labels all over the place takes up even more space and results in the whole block diagram exploding to an often impractical size.

Wouldn't it be nice to be able to do an Excel-type tool-tip, where comments will be hidden until hovered over with the mouse?

Instead:

    hover with mouse -> 

I have a need to keep two string indicators lined up as the user scrolls one of them. It would be great if I could use the event structure to capture scroll position. It doesn't look like that is an option. I didn't see this posted yet.