Probe on loop iterator

[Chringel]

I often want to see if a while or for loop is running by watching the loop iterator. Now I have to stop the program, wire the loop iterator to the border of the loop, add a probe to the wire and run the program.

It would be great that I could right click the loop iterator and add a probe while a program is running.

[tst]

This has already been suggested - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Probes-for-Loop-Iteration/idi-p/917379

[PhillipBrooks]

It should be noted that the original idea was proposed in 2009.

The last comment (that appears to be appended in bold to the OP's idea) states that it will be kept in mind, but may take ~2 years.

The post indicating ~2 years was made in Feb 2013; so no need to ask the status until 2015 or abouts. 

[tst]

> It should be noted that the original idea was proposed in 2009.

That was actually the very first day of the IE, so it seems like this is something that's on people's minds.

[AristosQueue (NI)]

If you notice, the status of that idea is *Declined.* We won't be doing it ever. It has been revisited multiple times and will not be open for conversation again.

[tst]

What? NI has said multiple times in the past (and Grant said it explicitly there) that declined does NOT necessarily mean "no", and that it might mean "we can't do this now, but it's still on our mind". Are you saying that that policy changed or that even the comment that you made there about still hoping a cool trick or new hardware would solve it is no longer true?

[Intaris]

I agree, the comment from AQ seems very final.  I mean, who would ever need more then 640k of RAM......

[AristosQueue (NI)]

I mean that this particular idea has been investigated from every angle we can think of and although there's always the possibility of something revolutionary making this viable, I'm trying to tamp down expectations on this idea. In theory, there's hope. In practice, there's not. 😉

[Darin.K]

What is/was wrong with allowing this possibility register spills and all with debugging enabled and optimizing it away with debugging disabled?  Debugging IMO allows a bit of leeway in terms of performance. 

[tst]

> What is/was wrong with allowing this possibility ... with debugging enabled and optimizing it away with debugging disabled?

If the main problem is with NI's frequently called VIs and tight loops then this sounds reasonable, as presumably they already have debugging disabled anyway.

I don't know if this would still be an issue in user generated tight loops where you would now need to know to disable debugging where until now that wasn't a requirement.

[Darin.K]

> I don't know if this would still be an issue in user generated tight loops where you would now need to know to disable debugging where until now that wasn't a requirement.

No pain, no gain.  I'd argue you are ultimately doing them a favor by demonstrating the benefit of disabling debugging in general, especially with tight loops. 

Of course some thoughtful person tried to make it easy to switch debugging on and off...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Easy-Access-Button-to-Enable-Disable-Debugging/idi-p/1...