Updating cluster values, is there a better way?

[Mark_Yedinak]

For cases like yours I prefer to use a typedefed cluster and and For loop with a shift register to update the cluster. The nice thing about my approach is that it is very easy to extend. Here is a screen shot of how it looks.

[Darin.K]

Sorry, I don't have LV9 on this machine, but looking at the code, you should be using a shift register in your For Loop to build the array of paths, otherwise, it is only the last value that is making it in.  This is a bug, but I am not convinced that it should throw a runtime error.

[RTSLVU]

---

Darin.K wrote:
Sorry, I don't have LV9 on this machine, but looking at the code, you should be using a shift register in your For Loop to build the array of paths, otherwise, it is only the last value that is making it in.  This is a bug, but I am not convinced that it should throw a runtime error.

---

I replaced the tunnel with a shift register, it still throws up the runtime error.

I guess there may not be a better way...

[RTSLVU]

---

Mark Yedinak wrote:

For cases like yours I prefer to use a typedefed cluster and and For loop with a shift register to update the cluster. The nice thing about my approach is that it is very easy to extend. Here is a screen shot of how it looks.

---

I'm not worthy... I do not understand what I am looking at here?

[Darin.K]

Before you give up, check the cluster order for your clusters.  Using this technique assumes that Master Log and Timers are at the end.

[Mark_Yedinak]

Sorry about that.

User Events and User Event Data are two typedefed clusters. In this case they are related in that I can have specific Event data tied to my user defined events. What the code is doing is registering the user events and picking up the data associated with them. It is using associated data for each event. However, this is not what is is important to you. What you really are interested in is that the User Event cluster is wired to the shift register of the For loop. Internally the case structure is controlling which element of the cluster is getting updated each iteration. The shift register keeps the value of the cluster current since the old value is wired into the Bundle by Name. The only element that will be changed is the one currently getting wired. All others retain their current value.

this approach is very easy to maintain and extend. Simply update the cluster tyepdef,  add a new case in the case statement for the new element and wire the appropriate value.

[RDR]

There is an input to the flatten/unflatten functions for prepending the array or string size, what if you wire a false boolean constant to both of these terminals?

Also, I've not seen you post this yet...what version of LabVIEW are you using?

I will try to track down the AE assigned to this forum thread to have them file necessary CARs.

-Bob

Message Edited by B O B on 11-25-2009 01:35 PM

[Darin.K]

I did not have your subVIs but I stripped it down and this works just fine for me.

[RDR]

I believe the issue lies with the cluster size setting on the array to cluster function:

Right-click and select cluster size, then set this to 15 for your VI.  Let us know if this works!

-Bob

[Mark_Yedinak]

---

B O B wrote:

I believe the issue lies with the cluster size setting on the array to cluster function:

Right-click and select cluster size, then set this to 15 for your VI.  Let us know if this works!

-Bob

---

I believe what you are saying is correct. I did want to reiterate though that the approach I suggested above is immune to this. This is why it is a very flexible and extendable way of doing this.