LabVIEW Idea Exchange

To make your code reusable as subvi's and have less connector space used the cluster is a way to go, but you need to define the types inside your cluster upfront.

If you want to add an other item inside this cluster you have to rewrite all the subvi's this cluster is wired to...... This is at least annoying. (or dull, boring, dreadful, tedious, dreary, tiresome, aggravating, exasperating, irritating)

If you could add new types of variables inside this "Dynamic Cluster Array" on the fly, you can expand the clusters on the fly when needed !

Example of a "Dynamic Cluster Array":

 Look also to the Search 1D node, to see how you can select an array cluster item.

You can read and write the cluster as normal clusters but if you want to read or write a variable that does not exist this variable is added.

Reading and writing this variable will add this variable in all clusters in the array, these variables will get the default value until your software changes this value.

This behavior is the same as structures in Matlab

John

Background:

LabVIEW has had a recent proliferation of datatypes that essentially store the same type of data: an ordered sequence of numbers.  We now have Array, Matrix, Waveform (+ Digital Data/Waveforms), Signal (!) and Image datatypes (and perhaps one could also include Scalar).

The Benefits:

Each datatype is optimised for its own particular application, making it simple to perform a particular set of operations on the data.  However each appears to be developed independently.

The Limitations:

Each datatype has different restrictions on representation, dimension (typically only 1D or 2D), and "metadata", and most built-in functions will work on only a small subset of types.  Accessing the data as a different type usually requires copying the underlying data, with consequent limitations on speed and especially memory.  I notice these limits especially in three situations:

1) I want to use a function written for one datatype on another datatype (for example, use the Wavelet Denoising function (or even simply Square Root) on an Image),

2) I want a way to work easily with 3D images (most of the existing 2D image processing functions would have simple extensions to 3D),

3) I want to write routines that will adapt to both 2D and 3D arrays (say deconvolution).

It is certainly possible currently to work around all of these things, but it seems there should be a more cohesive approach.

New LabVIEW developments:

3 new developments in recent versions of LabVIEW show potential for addressing this issue: Classes, In Place Element Structure, and Data Value References (DVR).  However because they are all ideas "in development", and added on top of the existing LabVIEW rather than under the core, they only hint at possibilities rather than provide them.

A Possible Solution:

A low-level generic Array datatype from which all these other types are "inherited", therefore providing a single common way of addressing array-type data.  It seems like this datatype could resemble either a Class or a DVR.  It would have various attributes associated with it:

- Dimension and Size - essentially specifies the way in which indices address the array (probably always stored as a 1D array underneath)

- Metadata - e.g. t0 and dt of Waveforms, name etc of Signals, border size etc of Images, ...

The In Place Element Structure would be one way of choosing how to access the information in this variable, although it may be possible for the array information to be directly available.  Hopefully something like this would also enable the ability to "overload" existing routines, for example adding a 3D convolution to the 2D and 1D routines that already exist.

Some of my earlier thoughts are here, here and here.

PS - hope no-one said Ideas here had to be practical or reasonable!

Hi

It is clear from the title itself what i want to say.

When are we going to see a function in the functions palette through which we can directly view the Excel file as an array in labVIEW!!! Everytime building a code using ActiveX and the property/invoke nodes is not comfortable. 

If the excel file has more than one work sheets, then the user must be able to select the desired worksheet. It should be able to display both 1D and 2D arrays