LabVIEW Developers Feature Brainstorming

[RobbieG]

In response to Ed, the reason you can't tell if I'm talking about adding something to the For loop or adding a new structure altogether is because it hasn't been decided yet.  I don't know how the "LabVIEW Developers Feature Brainstorming" board has been presented to all of you, but its purpose is for developers on the LabVIEW team (like myself) to throw ideas for new features (at various stages of development, I'd imagine) out to the LabVIEW community and get feedback on them.  Thus, every thread started on this board is from someone on the LabVIEW development team, and it should be regarding a perceived problem they're considering solving.  And it's up to all of you, the LabVIEW community, to 1) confirm or deny the perceived problem and 2) help us best solve it.  Obviously, we can't implement every idea suggested (sometimes they even conflict with each other), but they will all be considered as valid input, and they WILL help guide the decisions we make as we move forward to new versions of LabVIEW.

Now, having said all that, I want to say thanks to everyone posting here.  I'm getting some great ideas.  I want to answer one concern that seems to be cropping up a lot...performance.  Whatever changes, if any, are made to the existing for loop, I will make sure that there's still a way to use it with no performance degradation.  So, for instance, if I make a right click option "Show/Hide break terminal" on the for loop, then if that break terminal is hidden, it will behave just like a regular old For Loop. 

Right now, I think a good way to solve this is to add a break terminal to the existing for loop (which can be hidden or unwired so as not to slow it down).  In addition, for a lot of the other use cases mentioned, I think a Flex loop would be useful in addition to the changes to the for loop.  I think this would be a great way to simplify the syntax behind a lot of common use cases (such as "for i from 6 to 10 step 0.2").

Thoughts? (keep 'em comin')

Robbie

[JeffB_in_LV]

I would like to echo some of Dean's comments.

The idea is really cool (both when I heard about it earlier, and some of the new ideas discussed here).  Let's say we made it a visible-items right-click option on the for loop to "show break terminal" or something.  With this not shown (or when not using various other suggestions we might also implement), the performance must be as good as the existing for loop.

One of the optimizations that LabVIEW makes, for example, is allocating all memory for all auto-indexed output arrays on a for loop before it begins executing.  This is much more efficient than having an auto-indexed output of a while loop, since the while loop doesn't know how big the arrays are going to be.  If the for loop now isn't always going to generate N elements on the output arrays, things may not be as efficient anymore.  This may be OK, as long as we can keep the performance hits to a minimum and limit them to when the new features are actually being used.

[Albert.Geven]

Hi Jeff

The for loop with break should be as efficient as possible,
no problem with extra time for testing the condition,
no problem with extra time if the break condition holds and memory is deallocated from an already allocated array.

I guess we can leave that to the compiler, anyhow we will gain more readable programs and that helps to find the other bugs.

[BruceAmmons]

One thing I would like to add:  I would like to have the option to terminate a while loop when it is finished autoindexing an array.  I realize this is essentially the same thing as the for loop changes previously discussed, but it just starts from the other end (a while loop, not a for loop).  The only thing you would have to do is right click on an autoindexed array input and select "Limit iterations to array size" or something like that.  This might be easier to explain as changes to the while loop than changes to the for loop.

Bruce

[altenbach]

And while we are talking about indexing, let us select which dimension should be auto-indexed for multidimensional array inputs.

[IanW]

That's a very good suggestion. I'm not sure which is the highest probability a) my dropped toast lands buttered side down or b) my array is the wrong way round for auto indexing

Ian

[Greg_Cloutier]

Hello,

A for loop with a break would be great.  I also have a few other thoughts on how to improve the for loop structure.  Right now the loop count is set up by directly attaching a value to the loop count terminal or through array indexing.  An alternative to this could be terminals for ("i start", "i stop", and "i count") or ("i start", "i stop", and "i increment").  The first option would auto-calculate the increment and the second option would auto-caluculate the count.  Each option would feed the "i" value for use within the loop. 

It could also be useful to have an option where the break condition could be described on the outside of the loop.  A condition could be described based on a variable within the loop.  The variable could be tagged to any wire within the loop.  For this matter, you could set up many independent conditions with many wire tags.  One way to tag a wire could be like naming a net in a schematic capture program.

[Michael_Aivali…]

Been working with LV for more years than I can count. Still, I am not limited by the FOR loop. I really don't see a compelling reason for this feature. If you want to stop a loop, use the while loop! I think there are other features better worth persuing than this.

Use a while loop, Use a while loop, Use a while loop,...

Case in point... feedback node... another useless feature. I've never used it once..

[Bob_Y.]

I have also been using LabVIEW for quite a few years (>10) and I would love to see the ability to convert a FOR Loop into something stopable.  Everytime I wanted this I have had a FOR Loop setup already and then figured out it has to stop early.  So you convert to a WHILE Loop and start adding logic to make it a FOR or stop earlier.  It is not difficult, it does not take long (<5 min) and it is quite annoying!  If you could just pop-up a stop terminal and wire the logic, it would be much less annoying.

It's like the TIMED Loop.  It is fairly easy to add timing to a WHILE Loop, but having a sepatate structure for it is nice and the ability to convert a regular WHILE Loop to a TIMED Loop is great for those times where you finally figure out it is really what you needed all along.

As for the feedback node, I could see using one as a new user and finding it much easier on the brain than the shift register that it really is.  As a veteran, I will not use it as I already think in shift registers :-).

Thanks,
Bob Young

[TiTou]

I totally agree that there are much more "necessary"urgent" features than a break in a for loop...

I also love altenbach's idea :

"let us select which dimension should be auto-indexed for multidimensional array inputs"