Putting a probe on the real reentrant VI should put a probe on the clones

[AristosQueue (NI)]

This idea came from customer Jason Willis during an NIWeek 2012 brainstorm session with LV developers. To me, it seemed like a good idea, so I figured I would post it to the community to flesh it out and see what kudos it gets.

When you have a reentrant VI, you have the one real VI and many clone VIs. Debugging the clones is hard. One way to make it easier might be to make the probes behave like the breakpoints do.

When you put a breakpoint on an individual clone, only that clone gets the breakpoint. But if you put a breakpoint on the real VI, all the clones get that breakpoint. That gives you a way to stop at a point of execution regardless of which clone gets pulled from the clone pool.

We could make probes do the same: if you put a probe on a real VI, any time the block diagram of a clone gets opened, a probe would be added to its wires in the same locations as on the real VI. If you removed the probe from the real VI, all the duplicate probes on the clones would go away too. But if you added a probe to a clone, the other clones would not get a probe.

[elset191]

---

@X. wrote:
You have to put the probe IN THE CLONE, not the parent diagram. That usually requires stepping through the code until that clone is called and its diagram shown, A major pain in the rear, hence the need for that idea to be implemented.

---

I always use breakpoints in the parent diagram to get to the clones I need.  It can be tough to know which one you need if there's more than 1 clone at a time.

[TimVargo]

AQ,
Did this idea ever make any progress? My mouth is watering with anticipation. 😆

[CantankerousBullMoose]

I very especially want this to work with conditional probes. Anything to give me a shot at pausing/opening only the clone that's misbehaving, rather than opening every one that ever exists and crashing LabVIEW

[wiebe@CARYA]

And if probes can get references to the clones\clone date does that mean we can get those references as well? That would be nice.

[AristosQueue (NI)]

Weibe: Probes don't get references to the VIs that they probe. They're patched into the data copy proc of the wire that they're probing. All they get is the data value.

So... your question "If A then B?" can be answered as "Yes, but not A." 🙂

[wiebe@CARYA]

So those new probes can get patched into the data copy proc of the clones without getting references?

When\if this happens, we can probe into VIs, but we still don't get to know how many clones there are with VI server. Guess with this feature at least we can script a new probe and then hack the probe window to find it out. 

[AristosQueue (NI)]

> So those new probes can get patched into the data copy

> proc of the clones without getting references?

Yes.

[AristosQueue (NI)]

> Guess with this feature at least we can script a new probe

> and then hack the probe window to find it out.

I wouldn't expect that. Ignoring the fact that the probe watch window is a C dialog, not G, I wouldn't expect adding a probe to instantly populate the watch window with N copies where N is the number of existent clones. A shared clone pool may have an unlimited number of clones available, but any given run might only use a handful. Likewise, I've seen hierarchies where a preallocated reentrant VI is called in many places throughout the code. I expect that if LV added all the probes immediately, us programmers would have a harder time finding the useful results in that sea of <<Not Executed>> messages. Instead, I'd have LV populate the watch window only when a given probe executed. In other words, setting the probe on the master VI would hook the data copy procs for all the clones available. When a clone ran and executed that probe's wire in the clone, then and only then would the probe show up in the probe watch window.

[wiebe@CARYA]

More OT:

Will VI clones be full LabVIEW citizens in NXG?

The need to stop all running VI clones (during editing) is very basic, but getting it done is really hard right now.

[TimVargo]

I Kudoed this idea a long time ago, and I let that stand and hope that this idea eventually gets implemented.  But is there anything we can do now, in the meantime?  Yes there is, give LabVIEW Task Manager (LVTM) a try (sorry for the shameless plug).  It is an open source, community provided, free tool.

The main difficulty with dropping probes into clones, or stopping running clones, or pausing them, or even just monitoring them, is all about being able to get to the block diagram of the clone VI; as opposed to doing so for the reentrant parent, which is simple.  As mentioned in this conversation and others, there are several know tricks to accomplishing this (breakpoints, etc.), but as wiebe points out "getting it done is really hard right now".  The LVTM tool greatly simplifies this by obtaining references to all running clones, on the fly, so you don't have to!  It then uses VI Server to show you information about all VIs currently in memory, including all clones, and from there you can open the FPs or BDs of only the clones that you care about, and then drop your probes as needed.