how to extract element label from cluster

[Risuraj]

Hi,

i have cluster indicator contained three set of boolean array.how to extract each array by its  text label.actually i have attached a VI where i have string array(control) and cluster(indicator). i want to read 2'nd column of array control and compare to cluster array using text label and turn on particular led in cluster one by one.

eg: suppose i read Led_a_1_3  then i want to turn on led 3 in cluster array name Led_a_1.

[GerdW]

Hi Risuraj,

get the references of the cluster elements.

Use those references to read the labels of the elements.

Now you are able to find your "array LED_a_1".

Use the reference to read/change the array value…

Other option:

Create a large case structure, containing a case for each array label. Now you can use the array label to call the appropriate case and set/change array values using (Un)Bundle(ByName) inside this case…

[Risuraj]

Hi,

get the references of the cluster elements.

Use those references to read the labels of the elements.

Now you are able to find your "array LED_a_1".

Use the reference to read/change the array value…

can u share me VI file(remember cluster is indicator not a control)

[rwunderl · Accepted solution]

I believe something like this is what was suggested:

[Risuraj]

Hi,

i have attached a Vi where i am able to get text label of array but same time i want to take value also for associated text label.

Note:-My indicator cluster having boolean,string and boolean (1D and 2D)array indicator.at least for each how to get value.

[GerdW · Accepted solution]

Hi Risuraj,

---

@Risuraj wrote:

i have attached a Vi where i am able to get text label of array but same time i want to take value also for associated text label.

Which "associated text label" are you talking about?

---

@Risuraj wrote:

My indicator cluster having boolean,string and boolean (1D and 2D)array indicator.at least for each how to get value.

---

It's always the same approach: read the value as variant, then convert to specific datatype - as you already do for "DPS1_J4":

(Replace the string constant by a control. No error handling included…)

[altenbach]

You need to make a seperate case for each datatype. Here's one possibility.

(Or course there are probably better ways since the labels cannot change at runtime. It seems like a nightmare to keep track of all these names and make necessary downstream changes if the next programmer decides the rename one of the cluster elements)

[Risuraj]

what actually i want to do. i have "28p loco " is the cluster indicator consist of 1D boolean array,2D boolean array and other data type.

suppose i have one string "DPS1_J4_1" reading from some file.i want to match this string with cluster indicator text label.whenever i found string has matched.that time i have to turn on the array indicator inside the cluster.

eg:DPS1_J4_1 is matched with text label i have to identify that text-label element inside the cluster indicator  and turn first led from  DPS1_J4_1 array.what ever be the last value of string that particular led need be turn on.

[GerdW]

Hi Risuraj,

---

@Risuraj wrote:

what actually i want to do. i have "28p loco " is the cluster indicator consist of 1D boolean array,2D boolean array and other data type.

suppose i have one string "DPS1_J4_1" reading from some file.i want to match this string with cluster indicator text label.whenever i found string has matched.that time i have to turn on the array indicator inside the cluster.

---

Then you REALLY should rethink your data management!

Why do you want to rely on some indicator on your frontpanel? An indicator is a data sink - it should not be used as data source or data storage!

Create a data structure in memory. Handle the data by their labels. Use a FGV (or OOP or other means like those CVT implementations) to restrict access on the data to your own routines. Create a VI that reads the data and sets the FP indicator to show the user the current settings.

I recommend variant attributes (or maps in LV2019+) to implement your data handling! This will be so much better (scalable, error proof, etc.) than your current approach!