When to cluster and when not?

[jyang72211]

Hi all,

I have been taught to group similiar control/indicator in a cluster for subvi.  However, lately, I realized that it takes a lot of space to bundle and unbundle cluster.  If I have use cluster for the input/output of many of my subvis, I wont' have much space left.  However, I do realized that the cluster funciton document the block diagram nicely. 

Due to space problem, I start creating more individual single input/output instead of cluster, and it makes the code cleaner, but less documented. 

How do you draw the line?

Yik

[RavensFan]

If you have too many individual inputs and outputs to a subVI, you are going to have a crowded connector panel, and eventually there still won't be enough connectors to do all you want.

If you have too many inputs and outputs to a subVI, that may be a sign that the subVI is doing too much and should be broken down so that it does its basic function, but doesn't try to do too many things.

Elements in clusters should inherently be related to each other.  If you have more elements than that, then they should be in their own cluster.

If the amount of data is too much and needs to be used in numerous places, then I would consider using a functional globabl variable to store the data.  See Ben's Action Engine Nugget.

[jyang72211]

For example, let say that I have 4 inputs on a subvi. These inputs are related, so I can justify in putting them into a cluster.  However, there are enough space on the icon to make individual connection for all 4 inputs.  In this case, it seems like it will be cleaner to use a cluster, but bundling/unbundling would take a lot of space.  However, if I use individual connection, it will be a bit more messy, but I can save a lot of space, since I don't have to do any bundling/unbundling.  What do you think?

Yik

[RavensFan]

Four inputs do not sound bad.  I think your justified in leaving them separate.  If you got up to 5 or 6, then it's worth looking at combining them.  Why?  A recommended connector pattern is 4-2-2-4.  So that gives you 4 inputs and 4 outputs (keeping inputs to the left and outputs to the right).  Then you have 4 more which are in the middle and accessed from the top and bottom.  Basically 2 in and 2 out.  So now you have 6 inputs and 6 outputs.  (A 5-2-2-2-5 pattern gives you a bit more, but any pattern with more connectors than that is just too dense.)

So now you have 6 ins, and 6 outs.  You should probably have error in and error out terminals at the lower corners.  Many subVI's may need some reference terminals such as for queues.  They should to to the upper corners.  So now you are basically at 4 ins and 4 outs for the data of interest, which is what you have.

[battler.]

Clusters are great!

I agree with Raven. 

Why do only "similar" controls or indicators need to be grouped in Clusters?  I thought that was the job of arrays?!

I agree it takes a significant amount of BD space to bundle/unbundle, especially if bundle by name.  But how nice is the code to read!!!

You could save space by trying to bundle (not by name) as much as possible.

Because I can unbundle by name (advantage of not being affected by the cluster order) I can follow where inputs/outputs are flowing on the BD.  Most of all I hate all the spaghetti (wires) going everywhere.

Stick with clusters, bundle (not by name) where you can.

Message Edited by battler. on 03-12-2010 04:01 AM

[RavensFan]

Arrays are for identical datatypes.  Clusters are for when the datatype aren't identical.  For instance, I have a cluster where one axis, I am storing the current position and desired position (numerics), an enum, a timestamp, and a boolean.  Now I am repeating that data for 4 different axes, so I am using a 4-element array of those clusters.

If you need to bundle and unbundle, you would be doing that in the subVI.  There should be more screen space available there than in the higher level VI.

If the bundle/unbundle by name is taking up too much space, is it because the names of the elements are too long?  Suppose you have a front panel cluster, and one of those elements is "Number of Steps".  You want the full name so it is clearly understandable by the user.  But it eats up a lot of diagram space.  What you could do is rename the element "NumStp" so it takes up less space on the diagram.  Of course, that isn't as meaningful to the user of the front panel.  So what you do is hide the label of the control and show the caption.  In the caption, you use the full name of Number of Steps".

User gets fully descriptive control name, programmer gets a meaningful but abbreviated name on the block diagram.

[jyang72211]

Using caption sounds interesting.  I never really touch that.  I may start trying in the future.

Yik

[ben64]

If you look at Producer-Consumer examples you will see that cluster are also great to pass data in a queue. Also for multiple controls in a cluster you can sometime save space on the block diagram if you label all element in the cluster and then use the bundle and unbundle by name functions.

Ben64

[Mark_Yedinak]

---

battler. wrote:

Why do only "similar" controls or indicators need to be grouped in Clusters?  I thought that was the job of arrays?!

---

The same reason that you should try to minimize what a subVI does to a single task. It iseasier to maintain, more readable and easier to understand. Whay should you bundle unrelated things up simply for convenience? When debugging a problem later it would be very easy to miss something because you had no idea that unrelated items (the ones you are looking for) were stuck in some other cluster somewhere.

[JÞB]

---

jyang72211 wrote:

Hi all,

I have been taught to group similiar control/indicator in a cluster for subvi.  However, lately, I realized that it takes a lot of space to bundle and unbundle cluster.  If I have use cluster for the input/output of many of my subvis, I wont' have much space left.  However, I do realized that the cluster funciton document the block diagram nicely. 

Due to space problem, I start creating more individual single input/output instead of cluster, and it makes the code cleaner, but less documented. 

How do you draw the line?

Yik

---

You have been taught well!

and yes- using clusters does cause a space hit on the BD's  For now! looking forward, since this claims to be on the way, You can think about moving the line towards clusters and away from individual elements.  Ravens Fan's tip on using the caption is another graet idea on how to minimize the BD space effects.

Now I'd like to give you my take on "How to draw the line."  

Many good points were made- and a lot of posters have some well reasoned arguments for or against based on Connector panes, Style guides, BD readability and personal preferances.  Yet I think it is worthwhile to dig into what improves your code.

I've learned that only three things help me decide how to structure data:

• Abstraction-  Can I group these variables in a why that hides details at upper levels and displays the details where they are used?  A VISA Resource is a great example of abstraction One simple wire but, wow! access to each individual property when you need it.  A cluster is another good way to abstract data.  One discriptive name for a scalable group of variables.
• Encapsulation- Can I reduce the number of data containers by organizing them in a heirarchy?  Windows folders are one example- they don't really do anything but hold files in related groups.  This may be the worst excuse for using a cluster if your "filing system" is poor. 
• Cohesion- Can I reduce coding errors by demanding a special wire type?  By useing a type-def cluster you will see that the data must be passed as a group- you cannot accidentally cross two bools that the sub-vi uses or misswire any data type.  at the least youl break the vi where there are mis-typed clusters.

Again, this skill is something that each programmer developes with time but, intentionally exploring data managment concepts like abstraction, encapsulation and cohesion will help this skill grow like super-vitamins!