Probe terminal

[Norbert_B]

During implementation of code, the algorithm and its implementation has to be tested and debugged in most cases many times. For debugging, probes are a very useful tool. But probes can only be created on existing wires.

If, for any reason, the developer wants to probe values which are not on a wire already (e.g. iterator of a loop), he has to create an indicator (or tunnel) in order to have a wire. Once the debugging is done, the terminal/tunnel and the wire should be deleted.

I find it would be much easier, if i could right-click the data output and select Create >> Debug Terminal. This terminal is part of the code, but once i close the probe, the items created by this option (terminal and wire with probe on it) are removed automatically.

Norbert

PS: I know that there was a suggestion specifically for the iterator of a loop. I understand the reason why it was declined, but i find that using VI Scripting, the above mentioned functionality could be provided. As i WANT to have the information of that wire during debugging, i require that terminal/wire in any case. Using some automated tool would ease the debugging process with the hope to decrease time required to identify the software anomaly.

[PaulG.]

Great idea ... but I still want the iteration counter as well. I'm always going through tediousness of taking all these steps just to get the iteration count.

[AristosQueue (NI)]

Such a terminal would only be addable when the VI is not running and only on non-clone VIs. You are ok with that limitation?

[Norbert_B]

@AristosQueue: Sure. As this "probe/debug terminal" would follow the same rules as "standard terminals" for creation, it is expected. If there would be a nice trick to address clones, it would be awesome!

[AristosQueue (NI)]

I won't rule out the possibility of doing something for clones. Improving their debugability remains high on my personal wish list... just requires more resources than I typically have access to. 🙂

[GregSands]

I think a better solution would be to implement this idea allowing "single-source-but-no-sink" wires (or at least not breaking them), and then allow probing on that wire.

[X.]

dupicate of this: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-probe-on-other-than-wires/idi-p/984117

There is a universal sink here: http://forums.ni.com/t5/BreakPoint/Wire-End-Point-vi/m-p/2178108

[Norbert_B]

@X. & Greg: I know that there are several, similar sounding ideas around. Point is that imho my idea is currently doable with VI Scripting, so no need to meddle deep into LV. All other ideas i found require NI to change some very fundamental things in LV so it will not likely happen in a short term. My idea could be done in quite a short time, so i hope it is a feature in the near future 😉

[AristosQueue (NI)]

I thought about closing this as duplicate, but I think it is worth keeping on its own.

I find this one to be different from the "allow probes on other than wires" idea because the user experience here would be very different (no probe while VI is running, only if you did it before the VI started its run). It is also different from the "leave loose wires" idea because these would specifically be temporaries that LV would know to wipe out (pretty much opposite of the "leave loose wires" idea).

This idea of remembering that the code (even as small as a snippet) is a temporary change that should be forgotten when the project/VI closes is somewhat novel among ideas suggested for this problem.

[igagne]

What if there was an option for each output terminal on a VI. Something like "Allow probing in each caller" that would create the necessary infrastructure in each caller for probing that terminal from the caller. Performance wise, this could be the same penalty as wiring all the output terminals to the nearest structure. Functionally, it would be the same as having those wires available for probing without the visual clutter of having every terminal wired. You would not be able to probe if the callee had debugging disabled.