How to make a probe update itself

[Stobber]

Custom probes only update when the execution path runs through them, right? I have a custom probe that peeks behind a DVR and exposes lots of debugging information about the daemon VI the DVR is shared with. My application touches the DVR once and moves on, meaning the probe only updates that one time and then fails to give me information about the daemon later. How do I design the probe to continuously update without the app execution passing through it repeatedly?

[jcarmody]

I wrote a QD plugin that attaches a probe to a wire and launches another VI that'll works in the background.  The probe signals the background VI every time it runs, but you could program it to do something continuously.  I don't know if you could make it update the probe itself, though.

 

https://decibel.ni.com/content/docs/DOC-38903

[Stobber]

Yeah, if I can't update the probe's UI, it's basically useless to me. (The probe, that is.)

Edited April 13, 2015 by Stobber

[Antoine Chalons]

maybe an XControl could help you with this, no?

[Stobber]

It's never worth the effort to create (and then maintain) an XControl.

[Antoine Chalons]

I tend to agree with you but clearly that's not Olivier's point of view... Saphir's probes (see LVTN) are full of XControls

 

[edit]

of course if it's only for one project... it may not be worth at all

Edited April 13, 2015 by Antoine Châlons

[hooovahh]

I've used some debugging things like what you described in the past, but they were invoked by the tools menu, spinning off a VI that just monitored data that was more global.  I think your best bet would be as mentioned earlier, a probe which invokes a VI to be called which polls your data.

[infinitenothing]

Something like this but with better reference handling?

 

Edited April 13, 2015 by infinitenothing

[Stobber]

Something like this but with better reference handling?

 

That won't work if the probe VI doesn't update its FP until called again. It'll take an XControl...or something easier and more maintainable and easier to provide support for, like launching a "debug panel" that runs in the app.

[PJM_labview]

I have had to face the same issue in the past and I did not found a solution.

It just occurred to me though, could you subpanel the background monitoring async VI into your probe and see if the subpaneled VI UI update (even though the probe is not)?

I am not sure that this will work, but might be worth a quick try.

[Darren]

That won't work if the probe VI doesn't update its FP until called again.

 

I tried it, and the probe UI will update when the Fire and Forget VI runs, even if the probe itself is idle. I saw my probe happily incrementing while its owning VI was idle.

 

 

The biggest snag will be figuring out how to stop the Fire and Forget VI. It continues running even after the probe UI is closed.

[infinitenothing]

Did you see how I was trying to stop it? The front panel reference dies when you close the probe and the property node throws an error.

[Darren]

Did you see how I was trying to stop it? The front panel reference dies when you close the probe and the property node throws an error.

 

Ah cool, yeah, that seems like it would work.