[CR] Variant Probe

[Ton Plomp]

Name: Variant Probe

Submitter: Ton Plomp

Submitted: 03 Jul 2009

File Updated: 24 Aug 2012

Category: Custom Probes

LabVIEW Version: 2011

License Type: BSD (Most common)

Variant Probe V2.4.1

Copyright © 2012, Ton Plomp

All rights reserved.

Author:

Ton Plomp

tcplomp@gmail.com

Distribution:

This code was downloaded from:

http://lavag.org/index.php?app=downloads&showfile=19

Description:

A custom probe to put on a variant.

It will create a tree based on the variant data, and populate the tree with the data, the attributes of the variant will be shown as well.

The datatype description will determine the color of the tree items.

Historical data is available as well.

Version 2.0 introduces a Variant Tree XControl which can be used in any project. Located under the user.lib palette, it gives great flexibility to the programmer.

The programmer has the possibility to give the end user permissions for the following actions:

-Reset

This will reset the whole tree contents

-Traverse Variant Attributes

This will enable/disable the traversion of variant attributes

-Colorize

This will enable/disable coloring of the actual datatype

All of these customizations are available as properties/methods for the actual XControl as well, or you access them (while the owning VI is in edit mode) via the short cut menu.

Installation method 1:

Install the OGP file using VIPM (www.jkisoft.com/vipm)

and you have a custom VariantProbe and xcontrol

To use it add a probe to a variant datatype or to an array of variants.

It can pause if the data changes, and will notify you if a change happens.

Dependencies:

The following OpenG packages should be installed:

oglib_string>=2.6

oglib_lvdata>=2.8

oglib_comparison>=2.3

oglib_error>=2.0

Known issues:

Is slow on large variants.

Support:

If you have any problems with this code or want to suggest features:

http://lavag.org/index.php?showtopic=10269

Version History:

2.4.1: Fixed issue #132: An array inside another array crashes the probe/XControl

2.4: Immediate updating after changing of attributes

Rebuild in LabVIEW 2011

2.3: Fixed a bug that caused attributes not to be traversed on certain data-types

2.2: Fixed a relinking bug

2.1: Fixes a bug where unnamed cluster elements where used (http://lavag.org/topic/10269-discuss-variantprobe/page__view__findpost__p__67677)

2.0: Added an XControl

Show XControl in palette (under user.lib controls)

Add coloring

Add 'user permissions' on XControl

Add Reset on XControl

Add optionally traversing attributes on XControl

Add optionally colorizing on XControl

Add optionally restting on XControl

1.2.0: Upgraded to LabVIEW 8.5 to use inheritance

Support for Waveforms, timestamps and dynamic datatypes (thanks to Osvaldo)

Added probe for an array of Variants

Distributed as one .llb and added OGP installer

If a Variant hasn't changed it's not decomposed (optimization)

1.1.0: Support for attributes of variants

1.0.1: Controls placed on a seperate pane

Resize tree to upper pane

Hide unused columns

Limited maximum history length (default 10)

Window resizable

1.0.0: Initial release of the code.

License:

This code is distributed under the BSD License

Copyright © 2012, Ton Plomp

All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

* Neither the name of the Ton Plomp nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Click here to download this file

[crelf]

I'd like this to be rolled into the LabVIEW core - are you interested? If so, check this out: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Format-Variant-Probe/idc-p/1434322

[hooovahh]

Wow very tool tool, not sure how I didn't see this sooner.

One thing I wanted to bring to your attention that you may already be aware of. I found that some more complex data types cause the XControl to crash in a strange way causing me to have to kill LabVIEW. If the data type is an Array of Clusters, and in that cluster is an element that is an array, I will get the following error:

This error mentions to Right Click to fix the issue. But at this point if you right click the control, this VI becomes un-responsive and cannot be closed. If you don't right click the control you can still control the VI and stop and close like normal. This was seen in 2011 SP1.

Attached is the example VI I used which causes the error saved in 2011.

Is it possible to accommodate these more complicated data types? Or possibly just detect these data types, and not attempt to read them into the XControl so that this dialog and lock up issue aren't seen? Thanks.

Array Probe Test.vi

[Ton Plomp]

Hi Hoovah,

that was a bug on my side indeed. An array nested inside another array would cause this by trying to recursively call a non-recursive VI.

V 2.4.1 fixes this.

Ton

[QFang]

I install version 2.4.1 using VIPM, it shows up in LabVIEW under right-click custom probes, but when I try to place the probe it will say "cannot load the custom probe".. I've tried un-installing and re-installing the package.  It worked once upon a time, and it would be really super useful right now. :/

 

Any ideas what I could try?

 

Win7 pro (64bit)

LabVIEW 2013 SP1 (32 bit) no other versions installed currently.

[hooovahh]

I've discovered that there is some kind of issue with this XControl.  I don't know what it is, but running it for a while will cause LabVIEW to take a longer than usual time to close, indicating that there is likely references that go unclosed.

 

Attached is a VI that I think demonstrates this issue which I've seen in 2011 SP1, 2012 SP1, 2013 SP1, and 2014.  Basically I've seen that updating the tree XControl many times will cause LabVIEW to take a long time to close.  I use this XControl as a probe actor looking at various variant data.  This usually runs in the background updating a circular buffer as it runs.  The windows is only ever seen during debug but I had the control get updated throughout the test.  After a test was ran over night it took several minutes to close LabVIEW.  After some investigation I have isolated down to this XControl.  For me the fix is simple, if the UI isn't being shown, don't update the data.  It is a debug window and won't be seen often.  Still it should probably be looked into for those that do update it often.

Variant Tree Close Bug Test.vi

[hooovahh]

So I finally got around to looking into this issue, and I think I found the issue.  In the VI at this path:

 

<user.lib>\_LAVA\VariantProbe\AddValue.vi  We take the Tree reference, then get the Owning VI reference, the and the VI Panel Reference.  The issue is it looks like these are new references each call, and they aren't closed.  So the solution is to add 3 Close References at the end of this VI, one to close the Panel, the VI, and the Tree control (this one probably doesn't matter but still)

 

After adding these three closes, the probe seems to still work like normal, but the VI I posted previously doesn't take forever for LabVIEW to close.

[hooovahh]

I just realized this bug still exists and no update has been made.  So for others that might be interested in using this with this fix applied, I made the fix and rebuilt the package.  The spec has the version limited to >=2011 but I can't honestly remember what version I saved the VIs in and I only have 2015 installed at the moment.

Variant_Probe-2.4.2-0.ogp

[Antoine Chalons]

Is there a way to change the MCL column width once the XControl is dropped on a front panel?

 

Great tool!

[hooovahh]

Here is a quick and dirty edit.  It allows for column separators to be moved, but I noticed that on resize it will set the column widths.  So this means if you manually move the columns, and then resize the control it may change the columns in an unexpected way.  But at that point you can manually move the separators again.  I only have 2017 and 2018 so this is for 2017 and newer now.

Variant_Probe-2.4.3-0.ogp

[Antoine Chalons]

That's enough for my need, thank you very much for being so quick to make the fix!

[Antoine Chalons]

Would you consider making this open source?

[hooovahh]

It is open source.  It is licensed under BSD, which in layman's terms means you can use it for personal or commercial use, and various attributes must remain in the source, and you can't sue the author (I am not a lawyer).  I think the installed location is <user.lib>\_LAVA\VariantProbe

[Antoine Chalons]

Ok, great.

I guess we would need Ton's permission if we wanted to set up an online repo - GitHub for instance - for this package, right?

[ShaunR]

4 hours ago, Antoine Chalons said:

I guess we would need Ton's permission if we wanted to set up an online repo - GitHub for instance - for this package, right?

Nope. You may want to extend that courtesy but it isn't required for BSD.

Edited May 17, 2019 by ShaunR

[shoneill]

I seem to have trouble getting this working with classes. I'd like, if possible to have the name of a concrete class included as "Value.

I don't know how to go about that...... Anyone got some tips?

[Yair]

I don't use the variant probes, but a quick look at the code (browseVariant.vi) shows that it uses deprecated VIs in the refnum case. It looks like even the new NI VIs (at least in 2015) don't do the whole job (they seem to return the class name of the wire you had before you convert to a variant, rather than the actual class on the wire), so I think you will need a combination of NI's Get Type Information.vi to know that it's a class and OpenG's LVOOP Return Class Name__ogtk.vi to get the class name:

[shoneill]

I got the class name part working with the NI VI GetClassName.vi. I'm going tot try to get it working with FPGA DMA channels...... lol. Wish me luck 🤪

[shoneill]

I've actually gotten it to work with general refnums.

One note: If the actual value of the items is not important (which is the case for me - I just want to make sure all elements in a cluster have actually been assigned) then all the information required is contained within the TypeDefinition returned when performing a "Flatten Variant to String".  I've written parsers for this before, but that was like 15 years ago in LV 6.1....

[shoneill]

Hmm, of course I run into problems at the target boundary. The Probes don't execute in the same context as the FPGA code.

Using a FP control of the cluster I want to investigate (hopefully all Abstract classes have been re-assigned) I run into problems.  Concrete classes become abstract classes because the abstract classes are the only ones included with the Probe (On the FP).

I thought I saw yesterday that the information is passed as part of the TypeDescriptor of the Variant resulting from a conversion but I don't see that any more.

I suppose this is ultimately a serialisation / deserialisation problem across context boundaries. Unfortunately, I can't use Variant or String directly on the FPGA.......