Use a terminal block to access the for loop's data

[tst]

There have been numerous ideas on how to improve the for loop. Some people want more information. Some people want the option to have less. Some people want to be able to move the terminals or hide them altogether.

This suggestion should take care of some of these issues, and open the for loop for future expansion: Let the for loop data be exposed through a terminal block, similar to what event structures have:

This would be resizable in the same way that the event structure node is and would allow you to change the order of terminals. This would also allow NI to add additional loop data without worrying about cluttering the loop for those who don't want it.

Additionally, if NI implemented this idea, then we would also be able to hide this node entirely, which is useful in some cases.

Here are some relevant ideas which would be helped by this idea:

1. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Option-to-Show-Hide-the-Iteration-and-Count-Terminals-...
2. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Option-to-quot-Dock-quot-the-Iteration-Terminal/idi-p/...
3. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Sliding-N-Terminal-on-FOR-Loop-and-or-Progress-Termina...
4. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Reverse-Iteration-Terminal-in-For-Loop/idi-p/1174449
5. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Progress-Terminal-for-FOR-Loop/idi-p/1236224
6. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Diagram-Cleanup-should-not-move-loop-terminals-option/...

[Wart]

I like this idea, but it might be nice to be able to "decouple" the "i" terminal and move it around in the for loop.  I've seen it used at the right hand side of rather large loops before, and it's nice to cut down on wires.  I'd certainly like to see this style be the default.

[rgvdh@rdf]

Should the "stop" input on a conditional for loop become a terminal too, like on the right side of an event structure frame?

[GregSands]

I like the look of this, but one downside is that if you want to wire both N and P, and to also use those values, then you'd have a doubled stack of N,P,N,P -- not the nicest look.  One solution would be to move the inputs for N and P outside the loop (as an optionally-shown terminal block) in a similar style to the "Timed Loop".

That would also support the idea of "Stop" being a right-side terminal, and you could also add "Error" terminals which would effectively prevent further loop iterations from occuring.  In fact, having written this, I wonder why not just provide a "Timed For Loop"?

It's pretty easy to think of additional useful left-hand-side terminals, say "%" for a fractional percent completed, and "q" for the parallel-loop id.

[dthor]

GregS:

What about putting inputs on the left side of the terminals, exacly like there are for the current method? Then you'd only have N-P.

Note that I intentionally have two i terminals. I don't see anything wrong with it, and some people might find it useful to be able to have i output in more than one location. Having two N (or P or C or any input) terminals as in tst's image is a Bad Thing™. (Don't worry tst, I know that having an extra N in there was a mistake )

In general: I'm a bit skeptical about taking something as simple as a FOR loop and adding all these bells and whistles. They can possibly confuse new programmers and, if not taken care of, can cause fast loops to slow down.

[GregSands]

dthor: I did think of that, but it makes it a little more difficult to know which are input-only, which are output-only, and which are both.  The bar to the left is also a visual block to wiring them up.

[dthor]

Well I'd assume the standard in-out terminals would appear when hovering your mouse over an item, possibly solving your first issue:

However, I agree the bar on the side is a visual block. If we connect the wires through the bar on the side...

it looks ugly. Anyone else want to take a crack at it? 

[tst]

The N terminal was left in the corner in the original idea on puprose, so that it could be connected clearly from the outside. Personally, I would prefer if it could be hidden (as one of the ideas I linked to suggests), as I only rarely use it to set the number of iterations. The same would probably apply to the P terminal, although not having used it, I can't really make that claim with the authority of experience.

I probably wouldn't put the stop terminal in a parallel node, although I have no concrete reason for that position.

Also, I would probably not want this to be a timed loop. The timed structures are visually heavy and take up a lot of space. Having this as part of the normal for loop means it would actually be used.

[rgvdh@rdf]

"I wonder why not just provide a "Timed For Loop"?"

I think I'd prefer that, and leave the current one as-is.

[Wart]

You could shade the terminals to indicate which ones can be wired to and which cant.  Something like..

[altenbach]

> You could shade the terminals to indicate which ones can be wired to and which cant.  Something like...

Interesting. Makes you think what shoud happen if you allow things that you think you cant.... 😄

Of course wiring to [i] from the outside could provide an offset to be added to the iteration number. For example if I wire a 5, I'd get "5,6,7,8,9...." on the [i] terminal inside for the first iterations. Just another idea!