LabVIEW

[Umbagogger]

Is it possible to programatically determine the index (order) of a particular element in a cluster constant (typedef)?  The cluster is not a control cluster, so using the controls[] array is not an option.

It seems like this would be a property operation, but as there are no 'references' for non-control objects (are there?), there are no properties of non-control objects.  I use non-control clusters a lot.  I have struggled with the same issue when trying to retrieve cluster element names from non-control clusters (all roads lead to OpenG :-)  don't want to install VIPM :-( ).

I use a DVR of a cluster of arrays to share data across an app, and use in Place Element structures to read/write the the arrays. Each array (all BOOLs or DBLs) represents an array of values to write to output modules (digital and analog).  Generally I only update the arrays in one loop, and read in multiple VIs/loops.

From the start, I stored the data as arrays, but later in development I created cluster typedefs for clarity when using the data around a FP VI (mostly when reading the data from the array and displaying on indicators).

The exception to the write-once/read-many rule is when I simply want to set or clear a single BOOL bit.

Attached is an illustration showing 2 ways to do the same thing.

The DVR Read/Write Element structure on the RIGHT illustrates how I currently update a single element of a BOOL array.  In particular, I want to set bit-2 of an array named 'bOutputCmds'.  bOutputCmds[] is an element of a cluster named 'IoCluster', and the 'IoCluster' is shared throughout the app by a DVR named 'IoDataRef'.  Safely updating the value of the bit requires 3 In Place operation (In Place DVR R/W, In Place UnBundle, and In Place Array Index).

This works fine.  However, proper operation requires specifying the index of the bit of interest, in this case, '2'.  I could assign constants for all the particular bits, but it would seem more appropriate to take advantage of the typedefs I have created. The typedefs allow me to make changes to the IO assignments and describe the configuration in only one place.  The DVR R/W Element on the LEFT illustrates a way to update a single bit (safely) by cluster element name.

Extracting the index of element 'bLoadEna' (2) from the cluster typedef used on the LEFT would make the solution on the RIGHT much cleaner.

My backup is to replace all the arrays I originally put in the shared cluster with the individual clusters that later I so carefully defined, or, replace all non-control clusters with Indicator clusters. Either will work fine. Mostly I am technically curious as I tend to be bumping up against the limitations of non-control clusters quite often.  I seem to be a non-UI programmer in a UI world.

Actually, my last statement was rhetorical, but is really quite true.  My application is a headless embedded controller, so I do not need or use many controls.  Maybe I should think about that some before picking on non-control clusters...

Done.

Thanks,

Peter

[Umbagogger]

Sorry.

LV 2011. Windows 7. Pisces.

[johnsold]

The controls[] property node works just fine.  Controls is used in the generic sense to mean any control or indicator.  There is a separate propert node which can identify whether a specific "control" is a control or indicator.  The image below shows getting the labels of the indicators in the error out cluster.

I do not know of any cluster order property, but you can use the label property to find the indicator (control) you want, so long as all have unique labels.

Lynn

[nathand · Accepted solution]

Use the tools from my favorite library, the VariantDataType library, found in vi.lib\utility\VariantDataType, as shown:

The functions used here are "GetClusterInfo" and "GetTypeInfo."

[Umbagogger]

Thanks nathand,

Perfect!  This solves both the posted problem (get index), and the older get-name problem.

I tested wrapping this all up in a sub-VI (passing the cluster typdef, and a single un-bundled element from that cluster).  It would be perfect, but the selected element looses its name when passed to the sub-vi, so I have to use Variant Info to get the name of the selected element and pass the name to the the sub-vi.  The remainder is in the sub-vi (the name list and name search you illustrated).  Not as elegent, but at least it is a closed-form solution, meaning I do not have to both select the element (i.e. un-bundle) AND describe the element (e.g. string constant).

Awesome!!!

Peter