multiple instances of a cluster

[P@Anand]

One suggestion is:

1.Create the Cluster and make it type def.

2. Create a functional global and make it Reentrant.

3. Have different Read and Write option in an Enum and create seperate cases for each UUT with their name in the same cluster.

4. While reading from file write those values for each UUT seperately and take it wherever you need it.

[Ben]

---

@Akiel wrote:

I have a system containing 12 items that are similar but may have differences. I want to use the clusters to store information about each item so when i come to control the system I can act appropriatly according to this setup informstion. The data will include what signals are present, comms digital IO etc...

I would like each cluster to be specific to a UUT,

hope its a bit clearer

thanks for your time 

---

Does that post indicate that you tried what I suggested re: a type-definition and found it lacking?

If so post some screen shots to illustrate your dilema and we'll go from there.

Ben

[Jeff-P]

You say that you want 12 independent clusters, but are the elements in each of the 12 clusters the same (with different data)? If that is the case, you could make a UUT cluster and put that into an array so that you can have the information for all 12 UUTs stored in that array. The array would have 12 elements, each element is a cluster with all the information for a specific UUT.

Is that close at all to what you are looking to do?

[Ben]

Shot-gun approach ?

Ben

[P@Anand]

---

@Jeff-P wrote:

You say that you want 12 independent clusters, but are the elements in each of the 12 clusters the same (with different data)? If that is the case, you could make a UUT cluster and put that into an array so that you can have the information for all 12 UUTs stored in that array. The array would have 12 elements, each element is a cluster with all the information for a specific UUT.

Is that close at all to what you are looking to do?

---

Its a good solution.. Jeff-P

[Akiel]

effectivly yes an array of 12 clusters, but am concerned as ben says its a shotgun approach but it will do the job. I am thinking ahead to when I start to use it.

thanks for all your help I have a couple of things to try, will let you know which one works best

akiel 

[Ben]

---

@Akiel wrote:

effectivly yes an array of 12 clusters, but am concerned as ben says its a shotgun approach but it will do the job. I am thinking ahead to when I start to use it.

thanks for all your help I have a couple of things to try, will let you know which one works best

akiel 

---

Cool!

Please update this thread for the sake of those that will follow in your path.

What you decided on and why will help.

Take care,

Ben

[Jeff-P]

Hi Ben,

I am just curious if there is a more efficient way of doing this. If the UUT cluster is made into a typedef and then set up in the 12 element array, is that not an efficient way to store and manipulate the data for each of the 12 elements? I am always looking for new and better ways of doing things!

Regards, 

[Ben]

---

@Jeff-P wrote:

Hi Ben,

I am just curious if there is a more efficient way of doing this. If the UUT cluster is made into a typedef and then set up in the 12 element array, is that not an efficient way to store and manipulate the data for each of the 12 elements? I am always looking for new and better ways of doing things!

Regards, 

---

I hope it is.

If the 12 widgets require differnet data structures LVOOP.

Eg,

Widget 1 is DAQ and needs DAQ ref and widget 2 is serial and needs visa etc... since there would have to be diffeent data type and fields, LVOOP would only reuire the values that are actually used and they can be process as an array in a For loop. Without LVOOP the stuff inside the For loop would have to have a case structure to process each type of widget correctly. Adding a new widget would require updating the stuff in the for loop to support the new widget type. That code bing changed would require re-testing to make sure the new stuff works and the old was not broken. LVOOP would only require testing of the new widget Class.

Ben

[Jeff-P]

Thanks that is interesting! I was making the assumption that all of the instances of the cluster would have the same information fields, but what you described is definitely more efficient if different elements are using unique fields (such as VISA and DAQ references).