[CR] OpenG Array XNodes

[gb119]

Name: OpenG Array XNodes

Submitter: gb119

Submitted: 26 Apr 2011

Category: XNodes

LabVIEW Version: 2012

License Type: BSD (Most common)

OpenG Array XNodes v1.4.2.43 by University of Leeds

Author: Gavin Burnell

Copyright: Copyright © 2011, University of Leeds, 2002-2007 Cal-Bay Systems, Inc., Jim Kring.  2006-2007 MKS Instruments, Inc

License: BSD

Compatible LabVIEW Versions: >= 2012.

Compatible OS Versions: ALL.

 

Description:

This package simply reimplements the OpenG Array tools as a set of XNodes. This has the advantage that any array time (apart possibly from arrays of LVOOP classes) can be worked with rather than just those that have polymorphs in the original OpenG versions. The disadvantage is that you can't inspect the code, but it's the same honest !

 

What is an XNode ?

~~~~~~~~~~~~

 

An XNode is a type of LabVIEW library (like a LVOOP class, XControl) that defines a collection of vis that provide on-the-fly scripted nodes on on the block diagram in LabVIEW. In other words, they allow you to create a node whose code is generated programatically as it is dropped on the block diagram or when inputs are changed. This allows the developer to simulate some of the effects of LabVIEW's builtin primitives such as polymorphism, node resizing and edit time configuration.

 

Unfortunately, it is not possible to edit XNodes in the regular IDE (unless you work for National Instruments) as they are locked in the IDE. However, the individual vis are not necessarily locked and either by editing the xml file of the XNode directly, or with the help of some third party tools listed below, it is possible to edit and implement new XNodes.

 

For a fuller introduction, you are rrecommend to read Adam Rofer's "XNodes - A Crash Course" presentation (http://lavag.org/files/file/56-xnodes-a-crash-course-powerpoint).

 

For developing XNodes I use (a slightly modified) XNode Manager by Aitor Solar (http://lavag.org/files/file/57-xnode-manager).

 

There are also a couple of ini file settings that make it easier (but still not trivial) to debug XNodes:

XNodeWizardMode=True

XTraceXNode=True

 

At all times remember that XNodes are not a supported technology as far as NI is concerned (as of LV 2010Sp1 anyway) and you should expect neither sympathy nor support from NI if bad things happen as a result of using them. 

 

The algorithms used in this toolkit are taken from:

 

oglib_array v3.0.0-1 by OpenG.org

Author: Jim Kring <jim@jimkring.com>, Doug Femec <doug_femec@mksinst.com>

Copyright: 2002-2007 Cal-Bay Systems, Inc., Jim Kring.  2006-2007 MKS Instruments, Inc.  All rights reserved.

License: BSD

 

Description:

The array package contains several routines for operating on array data.

Click here to download this file

[hugo_fr]

Great !

I started the same for the Conditionnal Array Indexing in LV 7.1 xnode way,

It works for 1D array, and i tried to filter arrays up to 4D, by selecting the dimension to use, but it's impossible with LV 7.1.

If you want to implement the same fonctionnality, just look at my xnode.

Hugo.

;DAHR_ConditionnalArrayIndexing.vi

[Yair]

Hugo, note that what you have is an External Node, not an XNode. Those have been deprecated and any code you write which uses them will be unusable in later versions of LV.

[hugo_fr]

I know

It was just for testing scripting possibilities.

[gb119]

Ok I'll add that to the TODO list. Right after I get the palette files to play hice in 2009 onwards and finish the remaining OpenG vis!

New version 1.1.0.14 uploaded. Fixes some of the palette file issues in 2009/2010 and implements the Reorder array.

[gb119]

I started the same for the Conditionnal Array Indexing in LV 7.1 xnode way,

It works for 1D array, and i tried to filter arrays up to 4D, by selecting the dimension to use, but it's impossible with LV 7.1.

Thinking about this, the general case is quite tricky. I think I'd do a template that handled the 1D case - that's essentially what the existing XNode does. The 2+D input array being filtered by a 1D boolean array is relatively easy - a template something like this:

You'd then need to script creating the constant that initialises the shift register (pretty easy actually) and duplicating the innermost case structure cases one per dimension of the input array, editing the delete and insert into array nodes to wire the index into the correct terminal (trickier but probably do-able).

Handling multidimensional boolean conditional terminals as well makes my head hurt.

[Yuri33]

Thinking about this, the general case is quite tricky. I think I'd do a template that handled the 1D case - that's essentially what the existing XNode does. The 2+D input array being filtered by a 1D boolean array is relatively easy - a template something like this:

You'd then need to script creating the constant that initialises the shift register (pretty easy actually) and duplicating the innermost case structure cases one per dimension of the input array, editing the delete and insert into array nodes to wire the index into the correct terminal (trickier but probably do-able).

Handling multidimensional boolean conditional terminals as well makes my head hurt.

You're half way there. All multidimensional arrays (both the data array and the boolean conditional array) can be flattened to a 1D array which can make use of the 1D templates that have already been created. You then reshape the filtered array to the original dimensions. I don't have access to create XNodes, but that's what I would do.

[gb119]

Have now got XNodes for all the OpenG Array tools. Other than not caring about the type of the array the only extra functionality is that the Empty Array? XNode will work with any number of dimensions of array. Most of the XNodes still dump their generated code to the clipboard for testing purposes, so that will be turned off next.

[Yair]

You may need it for backward compatibility, but it should be pointed out that in recent versions the comparison palette has a shipping primitive for checking if an array is empty.

[gb119]

You may need it for backward compatibility, but it should be pointed out that in recent versions the comparison palette has a shipping primitive for checking if an array is empty.

I guess the OpenG packages should probably treat these as deprecated and drop them from the palettes - I was just blindly implementing the existing palette as XNodes for the fun of it...

[GregSands]

Have now got XNodes for all the OpenG Array tools.

When I install, I'm missing Index Array Elements. Should that be there also?

[gb119]

When I install, I'm missing Index Array Elements. Should that be there also?

Ummm, yes. Will try and work out what how I've screwed up the packaging...

Edit: Identified the packaging problem (somehow the how XNode had disappeared from my source directory - thankgoodness for SCC..., coupled with some weird linkage problems). Version 1.2.1 should have the missing XNode I believe.

[GregSands]

Ummm, yes. Will try and work out what how I've screwed up the packaging...

Edit: Identified the packaging problem (somehow the how XNode had disappeared from my source directory - thankgoodness for SCC..., coupled with some weird linkage problems). Version 1.2.1 should have the missing XNode I believe.

Thanks - these are brilliant! You've inspired me to try coding an XNode or two - starting with a couple of my own array routines. It's not the easiest, though the XNode Manager does help. Is that what you use? Any other tips? I did get my first one done (with a lot of code reused from yours) in a couple of hours.

[gb119]

Thanks - these are brilliant! You've inspired me to try coding an XNode or two - starting with a couple of my own array routines. It's not the easiest, though the XNode Manager does help. Is that what you use? Any other tips? I did get my first one done (with a lot of code reused from yours) in a couple of hours.

Yes, I use the XNode Manager along with a couple of other things. Most of the XNodes that I've down (both the OpenG and the other Array XNodes) use templating to avoid doing the messy scripting. Basically I have one or more vi's that have the code wrapped in a sequence structure. The structure and all the tunnels are tagged using the (slightly obscure) tagging api. Generatign the code is then just a case of moving the tagged sequence from the template vi into the XNode's working diagram and then wiring up the tunnels to the terminals. I've gradually adapted the templating process to reduce the number of vis that need to be written for any given XNode. to speed things up, I've customised the blank_Xnode that the XNode manager users - I've attached my current version on this post.blank_xnode.llb

My XNode State.ctl normally keeps an error cluster for determing if the XNode is going to be valid and if not, what the error message to return will be (Get Errors3 ability then uses this). The State generally has a variant to hold the type of array so that Get Terms can set other terminals to match the input array type and then I keep a vi reference which holds a statically linked Viref to the template (so that if one needs multiple templates, Adapt Inputs ability can select the right template and stuff it ointo the state. The Image ability can either use the XNode library icon, or alternatively get it from the VI template. The final bit of head banging is to get an entry in the palette file that works across the platforms. I mainly develop on 8.6.1 and that uses the XNode library icon and description in the palette, while newer versions of LabVIEW use the Help Ability.

If you make a palette of XNodes in 8.6 and then try and import it into 2009/2010 then all the XNode icons get replaced with the Help Icon and description. Even if you set the icon and description of the Help ability vi to be sensible, the text in the palette file ends up being 'Help.vi' which is not a self-fulfilling prophecy. If you create the palette in 2009/2010 then it seems to get the text string in the palette right. Until you edit the palette with the palette API vis... I eventually took the solution of simply naming the vi that implements the Help ability to be the same as the name of the xnode. That seems to work.

For the OpenG Array Tools XNodes, I wrote a quick an dirty helper programme that created a template with tagged structure and tunnels from one of the polymorphs of the originally OpenG Tools vis, used the polymorph vi icon and description to set the XNode library icon and description and that of the Help Ability vi to, and then inspected the template vi's connector pane to generate the details for the Get Terms3 ability. All that is left is to check the inputs to make sure they're valid, adjust the types of the output terminals and then package it up (which I always find to be the hardest part despite the cleverness of VIPM).

Gavin

[GregSands]

Basically I have one or more vi's that have the code wrapped in a sequence structure. The structure and all the tunnels are tagged using the (slightly obscure) tagging api. Generating the code is then just a case of moving the tagged sequence from the template vi into the XNode's working diagram and then wiring up the tunnels to the terminals.

The tagging thing confused me for a while, but I did work it out eventually (I was confused that the terminals weren't tagged until realizing that the tunnels were). Finding the example "Set Tag on Selected Object.vi" in your Scripting Tools made setting the tags much easier. It actually seems reasonably straightforward, though I've had more crashes (LV 2010) in the last two days than a whole year! One handy tip is having "XNodeWizardMode=True" set in my LabVIEW.ini file -- right-clicking to see the generated code is a big time-saver. I also have "XTraceXNode=True" set, but no idea what that does!

One question I have is whether anyone knows when and how the generated code is stored. Obviously, it is (re)created when the XNode is wired, or the input type changes, and presumably compiled when the VI is run. Does it store the generated code as part of the VI (i.e. equivalent to an inlined subVI)? Or is it recreated and recompiled every time the parent VI is loaded? How does it interact with the new ability to separate compiled code from a VI? Does the code inherit the same execution properties as the parent VI?

Oh, one more thing - with this obscure tagging functionality, do you know if you can get a list of all tag names? I presume not, as NI obviously use tags for all sorts of secret things, but it would be useful.

[Mark Balla]

Certified 6-8-2011

Placed in XNode Category.

[GregSands]

The latest version 1.3.0 (based on these revisions) has broken the "Remove Duplicates" function by not correctly retaining the Array Split in the In Place Element Structure. I presume this was caused by back-saving to 8.6, whereas this functionality is only in 2009+. That appears to be the only function affected.

[GregSands]

Here's a template that doesn't use the IPES, so should work in 8.6. It should be almost as efficient.

OpenG Remove Duplicates from 1 D Array Template.vi

[gb119]

Here's a template that doesn't use the IPES, so should work in 8.6. It should be almost as efficient.

OpenG Remove Duplicates from 1 D Array Template.vi

Many thanks ! This template is used in the new 1.3.1 version.

I've noticed one further buglette in the XNode - if you don't connect up wires to all of the inputs and outputs then it doesn't work (even if the outputs aren't then used for anything). I suspect this is the templating code failing to wire a tagged tunnel to a non-existent terminal but haven't had a chance to investigate it properly.

[hooovahh]

Old topic I know, but the recent VI Shots got me interested again.  I noticed that the Filter Array will be broken if the "Items to Filter" is a scalar and not an array.  The original OpenG ones accepted either an array or scalar.  This was on version 1.3.1.31 because I don't have VIPM 2014 yet, and I also want to support a reuse library of 2011 so to be fair this might be changed in the newer versions.

[gb119]

There certainly was a bug in filtering arrays of clusters with a scalar cluster in that version. If you aren't able to upgrade to the newer VIPM then you have a couple of options -

 

1) manually edit the template vi for that case (you'll find them in <user,lib>_LAVAcrOpenG Array XNodesOpenG Filter Array, you need to set the comparison mode of the equality est to compare aggregates (see attached image).

 

2) Download the latest source from github and unpack the zip over the installed files - this will get you the latest XNodes (but you probably want the latest Scripting Tools library as well, which will need to be manually unpaocked in the same way. Github repository is at: https://github.com/gb119/LabVIEW-Bits

 

The second way is preferred as you get the current version with the Petrify XNode feature (but only for the filter array so far !)

[hooovahh]

Thanks for your help.  Obviously the best solution is to just go to VIPM 2014 and use the newest, and also abandon support for 2011.  Upgrading VIPM is a cost that I haven't talked to management about yet.  But leaving 2011 behind is a decision I can make.  Thanks again for the info.

[Michael Aivaliotis]

Thanks for your help.  Obviously the best solution is to just go to VIPM 2014 and use the newest, and also abandon support for 2011.  Upgrading VIPM is a cost that I haven't talked to management about yet.  But leaving 2011 behind is a decision I can make.  Thanks again for the info.

Hey hooovahh. If you need to upgrade to VIPM 2014 contact me offline and I can help make the transition more affordable. - And thanks for being a fan of VI Shots!

[hooovahh]

Okay thanks for the info.  One more question (for now).  What magic did you use to get this to work in the Package Builder?  See I realize you have a custom MNU because VIPM's Package Builder doesn't recognize XNode files (as mentioned in the VI Shots).  But how did you convince Package Builder to have a sub palette, that is linked to an MNU file?  I can do this in a post install hook VI no problem, but what is interesting is if I open you package source in Package Builder, change something small like a description, resave and close, when I go to open it it will complain that a file has been removed from the palette and that connection between the subpalette and the custom MNU is lost.

[gb119]

Ok, this is what I did, (but not what I'm going to do....(

I installed the package with a blank palette, then in LabVIEW I created the palette file. Although LabVIEW doesn't offer .xnode as a type of VI that you can add to a palette, if you try it, it does what you'd hope. I then copy the palette file back to my package source folder and set it up to be a special target. Rebuild the package and it's good to go. The slight complication is that one could do this for free in VIPM 201x for x some number less than 4 but when I tried it recently I triggered the give JKI the money they so obviously deserve dialog (unfortunately I find it difficult to justify do this to the UK taxpayer  as releasing packages to the community doesn't obviously advance the specific research they're paying me to do  ). There's also some slightly complicated algorithm for selecting the icon and description that I think changes in different version - certainly everytime I think I've nailed it, something chnages and it breaks again).

The better way that Michael and Jack suggested after I raised this on vishots live is to use a merge vi that I can add to the palette. That's what the next release will do (when I've added petrification to all XNodes.