[CR] Array Function XNodes

[gb119]

Name: Array Function XNodes

Submitter: gb119

Submitted: 03 Jul 2009

Category: XNodes

LabVIEW Version: 2012

License Type: BSD (Most common)

lava_lib_LabVIEW_API_array_xnodes v1.4.3.36 by University of Leeds

Author: Gavin Burnell

Copyright: Copyright © 2014, University of Leeds

License: BSD

Compatible LabVIEW Versions: >= 2012.

Compatible OS Versions: ALL.

 

Description:

Description:

 

This is a collection LabVIEW 2012Sp1 XNodes.

 

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

 

Because XNodes are scripted at edit time they offer a form of polymorphism far superior to polymorphic vis as they will support any array type and not just ones that the developer has provided polymorphs for.

 

This package contains the following XNodes:

 

* Array Dimension Array

 

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.

 

* Array  Dimension and Index 

* Array Size and Unbundle

 

These are slightly different versions of the same XNode. It will take in an n-dimension array and return N I32 outputs with the dimensions of the input array. Array size and unbundle is perhaps the better named version.

 

* Array Dimension

 

This is equivalent to the Array Dimension Array coupled with an Index Array node to return as an I32 the specified dimension of the input array. If the specified dimension is greater than the dimensionality of the input array, -1 is returned.

 

* 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.

 

* Foreign Key Sort

 

Sorts one array based on the sort order of a second array - useful when you have an array of items and an array of keys and you want the first array elements in order of their keys.

 

* Shuffle Array

 

The inverse of an array sort - randomises the order of the elements of an array. For 2D arrays it can randomise either the rows, columns or both rows and columns.

 

* 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 1D 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.

 

Known Issues:

 

One of the palette entries is (a bit) broken: Array Dimension and Index appears as "Help" in the palette, but otherwise works fine.

 

Click here to download this file

[gb119]

The latest version of this (including a 8.6.x version) is available via the LAVACR subversion vepository on Google (http://code.google.com/p/lavacr/). As and when I regain ownership of the code repository file, I'll post an updated version of the array XNodes. Future developments will all be in 8.6 or greater.

[Michael Aivaliotis]

The latest version of this (including a 8.6.x version) is available via the LAVACR subversion vepository on Google (http://code.google.com/p/lavacr/). As and when I regain ownership of the code repository file, I'll post an updated version of the array XNodes. Future developments will all be in 8.6 or greater.

You might want to leave this as it stands for those that only have LV 8.2. Renaming it to [LV8.2]Array Function XNodes. Then create a new submission with the 8.6 version.

[gb119]

New build posted v 1.1.2 is now a VIPM Package file. No major changes in functionality, but should install a little more easily and has a palette file under a LAVAG Category.

Please ignore the slightly odd dependency of the .vip on itself. This is a result of a dirty hack that I've used to get VIPM to include a palette file of XNodes and is harmless

[gb119]

New version (1.2) adds an XNode version of the OpenG Array sort routine - uses exactly the same algorithm but works for any sortable array type without needing using polymorphic instances.

[dannyt]

HI

I was interested in playing with this to see what the performance of the Xnodes was compared to doing some of this stuff long hand, specifically the Unindex and Unbundle.xnode function.

Unfortunately, the VIPM package does not work in LabVIEW 2010, I suspect this is due to the formal release of scripting so I cannot install (due to conflicts) the package lavag_scripting_tools >= 0.21.0.0 which is seen as a dependency by the xnodes package.

Are there plans for a 2010 release some time

Also does anybody using these function have any comment about performance.

cheers

Danny

[gb119]

Unfortunately, the VIPM package does not work in LabVIEW 2010, I suspect this is due to the formal release of scripting so I cannot install (due to conflicts) the package lavag_scripting_tools >= 0.21.0.0 which is seen as a dependency by the xnodes package.

Have you installed the Scripting tools package from http://lavag.org/fil...cripting-tools/ ? That should provide the missing dependency (unless I've screwed up the packaging).

Are there plans for a 2010 release some time

Also does anybody using these function have any comment about performance.

I'm not using 2010 in production, although I've got it installed and as far as I know the scripting tools package works on it ok. With the release of scripting to the general public the need for the scripting tools package is rather less - they just wrap some scripting calls up a bit more neatly. I have seen some problems getting the custom palette to install correctly with some of these packages

Performance wise, the XNodes just generate static G code - all the scripting happens in the editor, so the resultant code should be close to what you would achieve with a sub-vi with the equivalent diagram to that generated by the scripting. There is a performance hit on the editor and compilation stage - especially when changing wire types and causing type propagation through the diagram.

[dannyt]

Have you installed the Scripting tools package from http://lavag.org/fil...cripting-tools/ ? That should provide the missing dependency (unless I've screwed up the packaging).

Thanks for the quick response actually loading the scripting tools package is my problem so I will move my question over there

cheers

Dannyt

EDIT question moved to link for clarity

[gb119]

New version released with a new Shuffle Array Xnode that randomises the order or elements in an array. A bit more explanatory text in the readme on the LAVACR entry.

[Xeledon]

Hi,

I have been using Array Function XNodes 1.4.0.24 for a while now and find them quite useful.

I have however encountered an unexpected behaviour with large arrays that makes me doubt the filter array node.

The "False Elements" output array of the node is too large, filled with elements of identical nonsensical data after the seemingly correct data.

My input array is U8. Its size seems to be the problem. If it is smaller by a factor of 100 the vi will work as expected.

I have attached an example vi that shows this behaviour on my machine.

Am i doing something wrong there?

Best regards

Florian

Error in Filter array.vi

Edited June 18, 2012 by Xeledon

[gb119]

I have been using Array Function XNodes 1.4.0.24 for a while now and find them quite useful.

I have however encountered an unexpected behaviour with large arrays that makes me doubt the filter array node.

The "False Elements" output array of the node is too large, filled with elements of identical nonsensical data after the seemingly correct data.

My input array is U8. Its size seems to be the problem. If it is smaller by a factor of 100 the vi will work as expected.

Hi,

Thanks for the error report. I've identified the problem and will release a new package shortly. In the meantime I can tell you how to patch the XNode to make it work.

The problem arises in the code used to count the number of filtered elements. I take an array of booleans into a boolean to zero-or-one node and then sum the resultant array. The problem is that the boolean to zero-or-one node outputs an I16

In the XNode folder find the template vi (<user.lib>/_LAVAcr/Array XNodes/Filter Array/Filter Array Template.vi probably) and insert a U32 conversion node:

You will need to force LabVIEW to regerenate the XNode after that. Forcing a type propagation should do the trick e.g. by changing the representation of some control upstream of the XNode).

Gavin

[gb119]

New package 1.4.1 uploaded. For reasons of having reinstalled my build machine, the Scripting Tools dependency is now the latest version on LavaG - although it doesn't actually need the latest version to work properly.

[Xeledon]

Hi Gavin,

 

thanks again for this great package and for the quick fix last time I had an issue.

I've been using some of the nodes (especially unindex and unbundle) extensively and unfortunately I've come across another minor issue:

 

Using unindex and unbundle with arrays of a cluster-typedef works fine in the development environment.

The minor nuisance is that when I build an executable containing this the build process is slowed down considerably because the application builder promts me to find those typedefs that are wired into that xnode.

I call it a minor nuisance because the build process will complete eventually even if I ignore the prompts and the code seems to work (altough whenever I build a bad exe that just needs a second build process to fix I can't help but wonder).

 

Is there anything I can do to fix this?

My guess is that this has something to do with the way the cluster type is determined. Unfortunately this happens in vis that are password protected.

 

Best regards,

Florian

Edited March 25, 2015 by Xeledon