Best Practices for LVOOP Probes?

[lvb]

I attempted to create some custom probes in my last LVOOP project and ran into a few stumbling blocks:

1. Default Probe is a Vertically Autosized Clustersorus

The ideal situation would be for LabVIEW to utilize the layout of the class private data control, but this does not occur (in LabVIEW 2010 at least). For large classes with a few levels of inheritance, these probes get large, ugly, and difficult to manage quickly.

2. Each Child Needs to Duplicate the Parent Probe

Unless I am missing something, I need to re-use the typedef and probe code of the parent for any child probe. This seems like a lot of busy work. Is there an easier way to create child probes containing the parent data?

I am curious how LAVA developers manage probes within LabVIEW. Any tips or tricks?

Regards,

Brian

[drjdpowell]

I attempted to create some custom probes in my last LVOOP project and ran into a few stumbling blocks:

I've tried adding a dynamically-dispatched method called something like "Text Description" to my classes, which outputs a human-readable summary of the object data. "Text Description" in child classes call their parent's "Text Description" and add-to or modify it, building it up (possibly through several levels of inheritance). Then this method can be used in a single probe that works on all child classes.

There are some probes of mine in this image from another conversation:

The probes themselves only work with Text. It works well if each level of the class hierarchy isn't too complicated, and can be meaningfully summarized in a few words.

-- James

[Aristos Queue]

The reason that we don't just use the private data control typedef is that there are several types -- mostly refnums -- where the display for probing is not the same as the control on the FP. The most common is an integer to display, but some of them, like the queue refnums, display as strings, populated with details about the queue. We decided that the generic probe for classes should follow the exact same behavior as the generic probe for all other types and let users build custom probes as needed for particular cases. At the time, it seemed the best way to handle it.

Probes don't automatically inherit. Honestly, I can't remember why... it was almost 8 years ago that we made that decision, and in all these years, I don't think anyone has asked me about it. Can anyone think of a good reason we would have done that? Given the way classes are constructed in LV, it probably took effort to keep that property from inheriting, which means there was probably a reason --- not necessarily a good reason, just a reason.

You can use the same VI that is in your parent as the probe for your child, you just can't set it as the default probe for the class. You can even select and use it if the VI is private in the parent class. Probes are debug, not part of your actual application, and as such, they just ignore the access scope rules. That way if your parent has defined something to explore the private parts of the parent, you can use that probe to explore the private parts defined by the parent on the child.

[Mike Le]

This is an old thread, but I was also working on some OOP probes. I can't offer much help in terms of the first problem (how to display massive amounts of class data), but perhaps I can help with the second issue (having to duplicate code).

 

I'll share my efforts so far. Hopefully since the original post, someone else has come up with something more elegant.

 

Here's the problem I'm trying to solve:

 

Basically, I have tons of abstract classes that end up being wires on the block diagram. During execution, I'd like to take a peak using a probe and see what's going on - but even though the wire is an abstract class, of course there's some concrete class that's running through the wire during execution.

 

I couldn't find a way to do a direct dynamic dispatch probe, so instead I created a simple "plugin" framework:

 

1) Created a probe for the abstract parent class.

2) Put a Subpanel on the probe's front panel.

3) Created a dynamic dispatching "Probe Facade" method for the abstract class, which takes a Subpanel reference as an input.

4) Dropped the Probe Facade sub-VI in the probe block diagram, inputting the reference to the Probe's Subpanel.

 

Probe Facade MUST be overridden by the child class. The parent Probe Facade must also be called in any override. The default behavior is to simply insert Probe Facade's front panel into the Subpanel reference. The extended behavior of each override is to read any child-specific private data and display it on its front panel.

 

The probe and Probe Facade VIs all need to be reentrant to probe multiple wires.

 

Now for my case, I wasn't especially interested in inheriting a default Probe Facade appearance from a parent class, because my parent was abstract. But I don't see why with a little modification you couldn't create some default Probe Facade and have children override only as necessary. Perhaps this takes care of the "busy" work that Brian referred to in the original post? Though I may have misunderstood what he was concerned about in that case.

 

My solution works most of the time, though I have noticed some inconsistent behavior if I have multiple probes active. Sometimes it looks like the Probe Facade errors out while initializing itself inside the subpanel. It's not super repeatable, though, so it's been tough to debug.

[Pie5669420]

Thanks for your post, Mike!  I've DVRs in my class private data, and your idea was just the trick to visualizing what I needed.

A few other notes in case they're helpful:

• Clear or handle run-time errors within the probe, especially if you're probing a wire in a loop
• The probe window in 2013 seems like it's bounded in size, so use tab controls to keep the window size small
• Hide the required custom probe interface to gain additional real estate in the probe window
• Dynamic dispatch VIs must be shared reentrancy, so there probably shouldn't be state in the probe

Edited January 30, 2015 by Pie5669420