Read/Write to controls in cluster using references?

[suttonsm]

I have a large typedef, ~1000 controls in a series of nested clusers. I would like to read and write to one of these controls at a time in a later subVI. Normally I would bundle/unbundle by name to get the control of interest, and perform the read/write as required, but due to the size of the typedef this isn't really an option. Since there is no way as far as I can tell to bundle/unbundle by name programatically, my idea was to

• generate an array of property nodes at startup, where each property node would be generated from one of the subclusters in the main typdef,
• bundle values from front panel controls into the nested clusters' controls
• Index the array from step 1 to access the Control RefNum of the control in question
• Read/write to it using a property node.

My issue is that the property nodes generated at step 1 only reference the values from startup (i.e 0), so even after I bundle new values in, I read the old values. 

In the Top_Level VI, I generate the property nodes. In SubVI_1, I bundle new values in. In SubVI_2, I try to read those values back using refnums and property nodes. 

Is there any way to achieve this without making new property nodes at every execution of SubVI_2? 

[cbutcher]

If retrieving the values as variants is OK for you, then yes, it's possible.

Here's an example (and then I'll explain the difference in your case):

Here I have references to Controls in two clusters built into an array (I used 1D and concatenate, you used 2D, but it's not important) and then I change the values of those controls, and then read the values from the references.

In your Top_Level image, you store the references to your controls (which I can't check, but I assume are from "All Data (two subclusters)") but you never change the values of the control. When you bundle the data, the changed data appears in the wire going out of the subVI, and eventually goes to the shift register. The input controls never update, so the references read the values of the controls they reference (the inputs) as expected.

I guess with such a large typedef there are probably a lot of restrictions on refactoring, and perhaps on code sharing, but you might get more advice on how you could work around this best if you can share a slightly more typical use case (along with more description of why you can't unbundle/bundle - you make it sound like perhaps you'd need a case structure with hundreds of cases, which would be definitely something to avoid, but it might not be the only way).

[Worle]

@suttonsm wrote:

My issue is that the property nodes generated at step 1 only reference the values from startup (i.e 0), so even after I bundle new values in, I read the old values. 

---

I am guessing that by 'create property node' you mean 'create reference'. If this is the case it probably means that the indicator/control that you have created the reference to isn't actually been updated. Are you sure you are writing to the same indicator that you created your references for.

I sometimes do what cbutcher has suggested with the addition of using the label text property node to programatically select which element I am after. It is slow though!! I would suggest at a minimum you only produce the list of element labels once and store it in a shift register.

A much more efficient method of indexing large datasets is to use an array with a type def enum to index it. Much quicker and memory efficient. This does require all of your data to be the same, although I suppose you could store it all as variants, never tried that before

[billko]

---

@Worle wrote:

@suttonsm wrote:

My issue is that the property nodes generated at step 1 only reference the values from startup (i.e 0), so even after I bundle new values in, I read the old values. 

---

I am guessing that by 'create property node' you mean 'create reference'. If this is the case it probably means that the indicator/control that you have created the reference to isn't actually been updated. Are you sure you are writing to the same indicator that you created your references for.

I sometimes do what cbutcher has suggested with the addition of using the label text property node to programatically select which element I am after. It is slow though!! I would suggest at a minimum you only produce the list of element labels once and store it in a shift register.

A much more efficient method of indexing large datasets is to use an array with a type def enum to index it. Much quicker and memory efficient. This does require all of your data to be the same, although I suppose you could store it all as variants, never tried that before

---

I've used the method you described above, but only as a last resort.  The code is fragile, as it would break the moment you changed the label of interest.  It all seems so unlikely until someone innocently changes a label and breaks the code.  Only it's not really broken because you won't have a broken arrow.  You'll have to slog through the code to find out why you're ending up with a default value.  Changing a label really shouldn't cause the application to quit functioning.

[Worle]

I agree. I sometime use it more for defining column headings in data files, although I prefer using enum indexes arrays. 

if I do use the framework I describes I tend to produce a custom error or just a message box if a label hasnt been found.