References from nested clusters

[1984]

Hi,

Currently our station can test only one product at the time, but we modified the wiring so now we can attach 2 units to the same station. A new application must be written to handle the new scenario. The test has to be executed several times on both the units. The execution is sequential so unit1 first then unit2.

I have created a CONTROL cluster with the following elements

- bool: boolean button (means unit enabled/disabled)

- PARAMS cluster: various text rings. This cluster is disabled and greyed out once the user enabled the starter.

- MEASUREMENT graph

Rules:

- the unit can not be enabeled if any of the text rings is unconfigured.

- the test must be interrupted immediately for the given unit if the enabled button is pressed during the test (when the user disable the unit runtime). So a reference to this button must be used and continously monitored.

- the test must be interrupted immediately for both the units if the stop button is pressed during thet test

- after a test is completed the results must be evaluated and the unit must be disabled if the measured values are outside of the limits.

now... This would be a very easy task if I would have one unit only. I would just create the neccessary control references drive them to the measurement VI and here we go.

But its getting inconveniently complex when I have control 2 units. I can not treat the control elements in an array (so like an array with 2 CONTROL clusters) because then I can not disable the PARAMS clusters independently.

I dont see an easy way to add 2 of the CONTROL clusters to a new cluster (so treat them as one cluster), I am not sure how to get the references in this way. (if I combine them into one cluster its pretty easy to get propertynode/value for any of the elements, but I need control refs)

So I handle both clusters as an independent control on the front panel, so I have add lot of duplicatinos to handle both units in the same way. I find this very inconvenient and error prone, plus it complicates the block diagram 

I am wondering what would be right approach to handle these type of problems.

(I have tried to create reentrant VIs but I gave up because I had to communicate too much between my main VI and the reentrant VIs. That made the code hard to follow)

I use LV2012, but the attachment in LV8 so hopefully everybody can open it:)

Thanks

[RyanPoPo]

Hey, 1984.

I'll be taking a look at your issue as soon as I can. I may have some questions regarding the specifics of your issue, so be sure to check back on occasion. 

Ryan

[0utlaw]

Hello 1984,

All you should need to do to access the control refs for the internal clusters is read the Controls [] Property for the top-level cluster.  This will give you an array of references to the objects contained in the cluster- in this case you'll get references to the two identical sub-clusters that can be cast, manipulated, and broken down further as needed.

Regards,

[1984]

Well... if I create a reference to the main cluster then I can use the controls[] property which will give me back 3 references in an array. First the button, second the params clusters, third the graph (maybe the order is different, it doesnt matter for now). But when I drive the params cluster reference to another property node it does not offer me a controls[] property, so I can not access the contents of the cluster itself. I may could use some sort of a cast function, but its really counter-intuitive.

I always have to know the order of any of the given clusters and if I change the order my code will mess up instantly. And hell, should why should I refer to my objects as control[][0], control[][1] etc instead of a real name.

Not sure if this can be resolved in the current LabVIEW environment...

The workaround I made is that I have created a cluster in which each element are references. I drive the button, graph and params cluster references into it and as I have two units to control I made an array of this cluster.

Not sure if you agree but this is overcomplicating the code and I had to create an extra cluster just to access to the references of my original clusters. Pain in the back.

Let me know your thoughts!

thx.

[1984]

Thx Ryan, let me know if you have anything for me.

[RavensFan]

I think a cluster of references is a pefectly acceptable solution and isn't that much of a pain.

Your probably need to take the reference you got that refers to the subcluster and use the To More Specific Class to turn it into a reference that will give you access to the Controls[] property of the sub-cluster.

The reason is that the top cluster controls is an array.  All elements of the array must be the same type.  Since they are references to different types of controls, they are all cast to a more generic class type that all of the references can be a part of.  Probably just the Control class.  Since not all control objects would have subcontrols, that class doesn't give you access to the Controls[] property.  Once you cast the reference to a more specific class (such as cluster), you should be able to get to the Controls[] property.

There is also a utility VI called something like Traverse for GObjects that will dig through the hierarchy of controls and get references to all of them.  It is heavily used in VI scripting.  It might give you an alternate means to dig down to the reference of the control you are looking for.

[Yamaeda]

Create an array of the cluster, and loop through your test on index X of the array. If you like, you can present it as 2 separate clusters on the main VI and thus easily enable disable them. The data should be kept as an array of cluster.

/Y