Break down cluster for subVI?

[tweberch]

Hi,

I have a basic question about programming style and cluster handling. 

I have a fairly big program. On the main VI the user makes about 10 different settings which are written into a cluster (item 1....item 10)

Some of these settings are used in the main VI but most of them are passed to a subVI. I used a cluster since it saves me of wiring 6 parameters to a subVI. But now, there are subsubVIs which are using just a few of the items from the first cluster. 

What is a proper programming style? Do you hand over the whole cluster with all the 10 items from subVI to subVI (every VI has in the end all the items even though most of them aren't used) or do you break the cluster up and pass just the parameters needed to the subVI?

I hope the question is comprehensible

Thanks

[crossrulz · Accepted solution]

It depends on what the subVIs are doing and what all is in the cluster.  In general, you can get better reuse if you unbundle the cluster and only wire up what is needed.  But if that is not a concern, then just make sure that cluster is type defined and just pass the whole thing around.

[tweberch]

Thanks for your answer.

[tweberch]

Does someone know if there is a good design guideline which covers how to make a neat program? 

Now that I have to work more with LabVIEW many questions about design are coming up.

Most of the time the coding is pretty straight forward but I'm thinking about things like if I should hide indicators on the front panel, when is it worth making a subVI or when to put things into a cluster and so on.

It's hard to find a good combination. I don't wanna have to much unnecessary code in the main VI but don't wanna nest dozens of subVIs

[crossrulz]

That is a very loaded question.  You can research SMoRES, SMURF, and a few other methodologies.

My main driving force for making subVIs is reuse.  I have a decent sized library that I have grown over the years and have used them on many projects.  Each time I reuse code, I  am saving myself time.