File Name: Array Xnodes.zip
File Submitter: Gavin Burnell
File Submitted: 3 Jul 2007
File Updated: 23 Jul 2007
File Category: XNodes

Array Function XNodes 1.01.01
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Copyright © 2007, University of Leeds, UK
All rights reserved.

Author:
Gavin Burnell
G.Burnell@leeds.ac.uk

Distribution:
This code was downloaded from the LAVA Code Repository: http://forums.lavag.org/downloads.html

Description:

This is a collection LabVIEW 8.2 XNodes.

XNodes are a hidden and unsupported feature in LabVIEW 8.x. As such, this code may not necessarily work in versions of LabVIEW > 8.2 and the technology is not supported by NI. On the otherhand they are really quite useful.

To use the XNodes, place the *.xnode files onto a function pallete and then use them as any other primitive or sub-vi. Because XNodes are scripted at edit time they offer a form of polymorphism far superior to polymorphic vis.

This package contains the following XNodes:

* Array Dimension.xnode

This XNode will return the n'th dimension of the input array, or -1 if the use specifies a dimension number greater
than the number of dimensions of the array or a dimension less than 0. In terms of primitives this is a combination
of an Array-Size and Index Array with some bounds testing. This XNode itself uses the Array Dimension Array.xnode

* Array Dimension Array.xnode

This XNode operates in a fashion similar to the Array size primitive Xnode except that it always returns an array
of sizes of dimensions. For a 1D array, this is an array with 1 element, for n-D arrays where n>1, this is the same as the primitive and for scalar inputs, returns a zero length array.


* Filter Array

This XNode splits the input array into two sub arrays according to a boolean array input - one for elements where the boolean filter was true and the other where the filter was false.

* OpenG Style Filter Array

This XNode is a drop in replacement for the OpenG Filter Array polymorphic sub-vi. Because this is an XNode it will handle any array type and not just the specific polymorphic instances of the OpenG toolkit. Additionally the XNode can return included or excluded elements and for string arrays can do a regular expression test.

* Unindex and Unbundle.xnode

Performs the inverse of Index and Bundle Cluster Array. Takes an input array of clusters and un-indexes and unbundles each cluster and returns arrays of each element of the original clusters. This is equivalent to feeding
a cluster array into a for loop with auto-indexing turned on, unbundling all elements, and wiring back out of a for
loop with auto-indexing turned on in order to generate arrays of each element.

* Minimum Array Size

This XNode will take the input array and either make it at least n elements long, or exactly n elements long. If additional elements are needed, the default value for the element is used and the new elements are appended to the end of the array. For the fixed-size variant, if elements are to be removed, they are removed from the end of the array.

* Foreign Key Sort

This XNode will sort an array of anything according to a second array of 'keys', returning the reordered array and the sorted keys. This is useful when you have an array whose elements are not directly sortable, but where you can create a sorting key for them. Optionally reverses the sort as well.

Dependancies:

My Scripting Tools toolkit, version 0.16.01 or better. Available also from LAVA repository on:
http://forums.lavag.org/downloads-file87.html

I strongly recommend unzipping this and the Scripting Tools into the same directory and preserving the directory names. This should be sufficient to get correct linkage of the vi's. If things don't seem to work (XNodes not dropping correctly) try to mass compile the directory where you unpacked both zip files).

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

Change Log:
1.01.01 Fixed a bug in Unindex and Unbundle that stopped it working on a type-def'd array.
Added the Update State with Ref ability to allow newerversions to replace older versions of XNodes without breaking things.
Added the Foreign Key Sort XNode
1.00.01 Initial Lava submission.

License:
BSD License - see LICENSE.txt

Click here to DOWNLOAD this file

I really like that one.

Ditto that.

But I have some suggestions to make the tools (this and the scripting tools more usefull)

One good way to start when publishing code is to make a clear seperation between development en deployment. One way is to change the names of the files, OpenG builder has the ability to do so (unfortuntly the current public beta has no support for XNodes).
Second putting the deployd VIs in a well known position inside user.lib makes them easier to reuse.

I had a problem when using the Unindex, Unbundle Xnode that it was looking for the Make-1-wire.vi in the wrong location.

If the Scripting tools had been placed under vi.lib with euhm say OpenG Package Builder, and your development code of the XNode tools had been linked to those VI then there would be no problem.

This is not meant to be picky, only to help you.

I'll have a look tonight to have quick setup of the OGP and let you know how it goes.

Ton

PS Keep up the good work

Found a bug, the Unindex and Unbundle doesn't like Typedefs....

Try to connect this one to the input of the XNode.

 OpdrukLineData.ctl ( 6.37K ) Number of downloads: 254


Ton

Ho hum,

Ok will investigate that one when I have some time - can't think immediately why it should fall over on type defs.

Also will look into packaging for future versions...

Dunno if this is possible as I haven't played around with scripting, but here goes:

Feature request/suggestion:
Provide the ability to perform an "Initialize Array" function by feeding it an array of dimension sizes. This makes code more adaptable to different dimensions of arrays at run-time. Presently, one needs to drop down a specific # of dimension inputs at development time. An example from the Matlab world is how you can specify things like B = ones(size(A)), which initializes array B to have the same dimension as array A and sets all elements = 1.

-Kevin P.

I don't think this is possible since it would require defining the dimensionality of the output array at run time - XNodes run at edit time (it's like writing your sub-vi's as you drop them onto the block diagram - once they're wired up the data types of the inputs and outputs are fixed). The nearest one could do would be a node that had a variant output that could pass out a variable dimension array. Not sure how much use it would be since you'd need to know in advance how many dimensions you expected to convert it into G data.

Ok, got it (couldn't try your example 'cos it depended on another type def but could replicate the bug easily enough). Should have a new version ready tomorrow.

Problem is in the GetTerms3 ability vi on that xnode. I need to set the type of the outputs to be arrays of the cluster element types, to do that I use SetArrayInfo from NI's VariantDataType vis. SetArrayInfo wants a variant input containing an array, so I just recycled the input of the xnode which works fine until you try to SetArrayInfo on a type def.

Solution is to wire any random (non-type-def'd) array - see attached:

Thanks for the bug report - more always welcomed

New version released, fixes the bug with Unindex and Unbundle with a type-def'd array. These versions of the XNodes also support the "Update State with ref" ability which means they won't break vi's when I bump the version number up.

I've also added a new XNode - foreign key sort.

This is useful when you have an array of things that can't be sorted by the simple 1D sort primitive, but where you can derive a 'key' for each element which can be sorted. This XNode will take the array of objects and the array of keys and sort both arrays according to the order of the keys array. You can also right-click on it to have the sort order reversed.



You will also need the new version of the Scripting Tools (>0.16.01) for this version of the XNodes as I've added (and used) some more support routines for testing what inputs have been wired up.

I've tried to keep the relative paths consistent between my development system and the zip files, if you unzip both the Array XNodes and the Scripting Tools into the same directory I *think* everything should work, but if in doubt do a mass compile of all the code.

Sorry to make you happy. But it appears your OpenG filter array is not working properly the array of indices to filter should be reversed prior to deleting them from the array.

And does one of your VIs have a break point? Because somehow my code is not working properly and I can't close LabVIEW. Saying:
That I can't apply a save-all while stuck at a breakpoint:

Ton

Ah, ho hum, yes. One of the templates used to generate the code was missing the sort and reverse nodes to get the deletion right. In fact, on closer inspection I realised that there was a further bug in the templates - if one of the filter items was repeated then it would try to delete the same element twice- not clever and particularly easy to do when using the regular expressions to filter. Attached is a zip file of revised templates (I'll release a new version of the complete code soonish).
 OpenG_Filter_Array_Templates.zip ( 98.08K ) Number of downloads: 140





Ok, I'm struggling a bit here. The scripting tools doesn't have any breakpoints set as far as I can tell (Edit->Remove Breakpoints from Heirarchy) returns 0 breakpoints for Scripting Tools:All vis. I've checked the OpenG Filter Xnode and it seems ok, are you using any other of the XNodes in the problematic vi ?

To be honest the VI is kinda complicated, it contains the State Diagram Toolkit, Xnodes and XControls. If I close my VI LabVIEW won't show the Getting Started Window. And if I kill my process I get the message as shown. I know XControls have specialabitilies on closing and saving and I believe Xnodes have the same so that might be a pionter.

Ton