[CR] Cyclic Table Probes

[drjdpowell]

View File

Cyclic Table Probes

---

A package for creating custom probes with "history"; showing the last N values rather than just the latest.  Values are displayed in a cyclic table, which wraps around automatically when it reaches the bottom of the display window.  Developed to support messaging systems, where messages can be handled too quickly for the eye to see with a last-value probe.  Included are some standard probes, for strings, variants, objects, and some numerics.  Also included is a "Text Variant" probe, for messaging using a cluster of such, and a "JKI State Queue" probe for use in designs using the JKI "state machine" template (see image).  But the expected use case is for very easily creating custom probes for whatever messages one is using (just modify one of the included probes).

Also includes "Quick Timer" probes to rapidly time execution of portions of code to accuracies of as low as 10 microseconds.

Now hosted on the LabVIEW Tools Network.

JDP Science Tools group on NI.com.

Requires VIPM 2017 or later for install.

---

• Submitter
  drjdpowell
• Submitted
  11/16/2013
• Category
  Custom Probes
• LabVIEW Version
  2013
• License Type
  BSD (Most common)

 

[hooovahh]

I like how you actually handle window resize properly where a very large majority of the custom probes do not.  I also like the ms timer column.  Have you ever thought about having a dt column?  Or replacing the ms timer with a dt column?  I only ask because it isn't too important to me that case A was handled at 3946013 and case B was handled at 3959319.  What is useful is how much time went between the two cases, which can tell me how long it took to execute case A.  I can of course get that information if I do math but it would be nicer if the probe did it for me.

 

At the moment I'm using VIBox Probes by SAPHIR which has a History Probe for strings.  This has a few features yours doesn't like being able to set the history length to a number (not window size), and being able to pause based on the string value.

 

One feature neither you nor the History Probe has that I've thought about is the ability to Pause the probe.  I haven't needed to use this feature yet so maybe it is stupid, but I wonder if it would be useful if you could press a button and then have it no longer update the probe with new values but have the VI run like normal.  My use case is what if my VI is running like normal, and then I see some case happen that wasn't expected.  The probe will overwrite its values if the VI keeps running and handling cases but I may want to see a snapshot of the cases that were handled to figure out what led up to going into that case.

[drjdpowell]

I had original made similar probes using an Xcontrol, with the idea that display customization would then be easy (and clean, using right-click menus).  But after a lot of head banging I abandoned Xcontrols as unsuitable (lossy if asynchronous; too slow if synchronous) and wrote this package in an afternoon.  They are, thus, very 1.0.  Haven’t felt much need for a pause option, as I can always just select a different probe for that, and I use these probes in debugging communication between parallel processes; pausing one process while the others continue can be unhelpful.  

 

Adding a “pause the probe” option is very easy, though, and I see that Saphir’s probe has this option (labelled “Freeze display”).  I’ll consider that for the next release.  Thanks.

[Mark Balla]

Certified 4-15-2014

Placed In the Custom Probes Category.

[drjdpowell]

Latest version has an improved Object Cyclic Probe that uses XML flattening to display the contained data in arbitrary objects.  An example is below, where I am debugging the command pattern in the Cyth SQLite Logger:

 

Edited July 26, 2016 by drjdpowell

[drjdpowell]

Latest 1.4.4 version adds a set of "Quick Timer" probes.   These probes are intended to support rapid identification of slow points in code.  They are very simple probes that chart the time since the previous call of any other Quick Timer probe.  The time uses the High-Resolution Timer, and the probes are simple enough to execute in roughly 10 microseconds, so one should be able to usefully time sections of code that execute as fast as about 50 uS.  Use is very quick, too, as one just adds probes along a chain of actions.  Each probe charts the time from the previous upstream probe.  Currently there are probes for Strings, Objects, Variants, I32s and the Error Cluster, and you can mix the types.  Below I'm using the Object version to time SQLite actions, but I could have put some of the probes on the error wire instead.

 

[Bobillier]

Hi, thanks for this upgrade, but I think there is one problem with your VIPM package. When I try to install it, it refers to VIPM2017 who not exist and refuse to install the package.

 

Oups sorry for my error. VIPM2017 seem existe, but like on JKI site they refer to VIPM2016 .

Thanks again

Edited June 29, 2017 by Bobillier

[drjdpowell]

You need to upgrade to the latest 2017 version of VIPM, as that's what I used to build the package.

[Tim_S]

14 hours ago, drjdpowell said:

You need to upgrade to the latest 2017 version of VIPM, as that's what I used to build the package.

May be easier said than done. VIPM 2017 installed with LabVIEW 2017 for me. My coworker tried downloading from JKI's website and got 2016 instead. That's been a week or so ago so it might be fixed now.

[hooovahh]

Yeah there was a post on the JKI forums about it, and I went and tried and even though the download said 2016 on the page, the link was to 2017.

[Tim_S]

11 minutes ago, hooovahh said:

Yeah there was a post on the JKI forums about it, and I went and tried and even though the download said 2016 on the page, the link was to 2017.

Ah, good to know. Thanks!

[pktl]

Hello everyone,

thank you for these probes. They make debugging much more enjoyable

One question, though: Is there a way to make them work in a debugging executable? The debug session crashes as soon as I select one of your probes. It makes sense, I guess, since probes are not recognized as a dependency and are therefore not included in the build.

Is it enough to add them to the 'Always Included' list? If so, which files exactly are necessary?

[drjdpowell]

I've never even tried them on an debugged executable.  But it is likely the same issue that causes crashes on RT: use of a pane resize event to detect when the User resizes the probe.  I now conditionally disable that on RT.  I'll investigate when I get a chance.