LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Can I probe a dynamically dispatched shared clone reentrant class member vi?

Solved!
Go to solution

Please there must be a way. 

 

Currently I am forced to change the VI to non-reentrant execution, debug, and then turn it back to shared clone reentrant execution.  Obviously there is a reason I have it on reentrant execution so this is not ideal.

 

Any ideas?

0 Kudos
Message 1 of 10
(5,188 Views)
I don't know if i understood correctly. You can keep break-point in VI and check isn't it?
Thanks
uday
0 Kudos
Message 2 of 10
(5,171 Views)

One way to do this is to create an ordinary VI with a single control of the type that you wish to probe.  In your Reentrant VI, in place of a Probe, put this "Probe VI" in, wiring the value you with to probe to the VI's control input.

 

This sub-VI will, of course, appear in all of the Clones (assuming you call the reentrant routine more than once), but will at least "report" the value(s) it receives.

 

For example, I made a Reentrant VI that counts from 0 to 9 once a second, then stops.  I want to "see the count", so I wire it to my "Probe" VI that is nothing more than a Control.  As long as I have the Probe VI in memory so I can see its Control, I can "probe" the detached clone.

TEST Spawn Reentrant.png

This (below) is the Probe VI (pretty simple, no?)

PROBE Value.png

 

Bob Schor

Message 3 of 10
(5,161 Views)

Hi Bob, yes this is a pretty simple solution thanks.  As you say it will unfortunately show all the updates made by all the active clones of the reentrant calling vi, but at least I can see some activity.  

 

So it seems there is no way of probing an overriden dynamically dispatched member vi if it is reentrant?  For non-dynamically dispatched reentrant vi's I can simply drill down to the clone in question from the calling vi, open the clone and probe it, but the clone's diagram seems 'dead' if it was dynamically dispatched.

 

0 Kudos
Message 4 of 10
(5,146 Views)
Solution
Accepted by topic author AnthonV

@AnthonV wrote:

So it seems there is no way of probing an overriden dynamically dispatched member vi if it is reentrant?  

 


No, it is easy to probe such a VI, if you can open it's front panel.  You can't open the FP the usual way, but there are multiple ways to do it.  Putting a breakpoint in the "master copy" of the VI will also put breakpoints in the clones, causing them to open their FP.  Also, try clicking on the subVI and selecting the menu item "SubVI Call Setup.." and then selecting "Show Front Panel when called" (or do it for all clones in VI properties).  You can also use the "Single Stepping" debug tools to "Step into" the subVI call.  And from the master VI you can select "View>>Browse Relationships>>Reentrant Items" to open the clones.

 

Added caveat: unless your on RealTime, in which case your stuck.  

Message 5 of 10
(5,134 Views)

OK sneaky but useful.  Here is my feedback on trying these ideas on Windows:

1) Breakpoint method.  This seems to work however the breakpoint actually has to be triggered for the front panel to open, meaning that the execution is interrupted.  Not a problem though as now that the vi is open, I can restart the program and the probes will still work without needing the breakpoint to trigger.

2) Rightclicking on call and selecting SubVI node setup: works but can get crazy when many different types of child classes are dynamically dispatched from this call.  

3) Setting open front panel when called from the vi properties: works better in my case as I only want to see this one specific child class' implementation of the vi.

4) Single stepping: not tried

 

Although I do most of my debugging in Windows, the application is actually deployed to a desktop RT system.  I'll try these suggestions on Monday on the RT system while debugging from my Laptop (i.e. not running headless).  

0 Kudos
Message 6 of 10
(5,121 Views)

I am not having much luck when I try the same techniques in RT (that is, I am targeting a RT desktop but I am still attached to it using my LabVIEW development laptop).  Is this a known feature/issue?

0 Kudos
Message 7 of 10
(5,070 Views)

@AnthonV wrote:

 Is this a known feature/issue?


Yes.  The remote FP/BD thing used to debug RT is not even implimented for shared-reentrant clones, as far as I understand.

Message 8 of 10
(5,066 Views)

That's a pity now isn't it?  I'll use Bob's solution in the RT case.

0 Kudos
Message 9 of 10
(5,053 Views)

Dr. Powell,

     I didn't know you could directly probe "Clones"!  As it happens, I'm trying to "abuse" the new Channels that come with LabVIEW 2016 to be able to use them in asynchronous VIs started with Start Asynchronous Call -- they cannot be passed in or out as parameters, but I'm trying to subvert this restriction.  In the course of this, I needed to "probe" the Clones, but was having trouble ...

 

     I'll definitely try (some of) your suggestions!

 

Bob Schor

0 Kudos
Message 10 of 10
(4,977 Views)