Front panel cluster makes VI unresponsive

[andrej]

Hi,

I have a VI that have large cluster (strict type control) on the front panel. Cluster contains numeric, arrays of numeric, references and classes, it does not contains complicated structures. This control is used by many VIs in the a project (it is fairly a large one containing more than 1000 VIs). The problem is that when I change something in the cluster (add new control, delete one,...) it takes quite some time to update everything and the VI becomes unresponsive (sometimes also LV 2012 crashes). This is probably due to all the updating that it has to be done.

I am looking for a solution to a better performance. Maybe data value reference is the solution (I have no experience with it)? If I put the control into data value reference and the pass this reference into VIs, will this result in a better performance?

Any other suggestions?

Thanks!

[DFGray]

There are several solutions you might try, depending on how your code is architected:

1. Close everything before modifying the cluster.  This may not be possible or desireable, depending on what else is going on.  This is what I usually do in this situation.
2. Break your cluster into smaller clusters so fewer things are dependent upon each piece of it.  This could take awhile.
3. Replace the cluster with a class.  Updating the class data should not cause all the references to update.  This could take awhile.

I don't think using a data value reference will cause the problem to go away, since DVRs are also strictly typed based on the data they contain.  I could be wrong, since I have never tested this.

If you are going to do refactoring on the order of items 2 or 3 above, you may want to rethink how you can change your architecture so you don't have to pass that much data around to that many subVIs.  Consider messaging and actor based architectures, where data for each process/actor is stored locally and passed around piecemeal using messages (usually queues).  It would be an intial time outlay, but your code should become more easy to manage.

[Freelance_LV]

---

@DFGray wrote:

There are several solutions you might try, depending on how your code is architected:

1. Close everything before modifying the cluster.  This may not be possible or desireable, depending on what else is going on.  This is what I usually do in this situation.
2. Break your cluster into smaller clusters so fewer things are dependent upon each piece of it.  This could take awhile.

---

I would do either the first or the second option suggested by DFGray.

Though, my priority would be option 2.  It is easy to edit smaller clusters. If you are placing the type def control on the GUI, use small clusters and arrange them to look like one.

You could customize the clusters to look transparent/ or of the same color background, along with using some decorations.

[andrej]

I'm not useing cluster to show data on my front panel, but to pass variables throught application. That is why I,m thinking about data value reference. Breaking it into smaller clusters would not help, because I cannot have 20 input terminals.

[Freelance_LV]

hi

in that case, you should go with option 1 of DFGray. While you edit the cluster contents, close all other project files. you can even close the project, open the control from its path (not from projecT), edit and close.

also, want to know if you have kept your cluster auto sizing option as 'Size to Fit'. i would usually keep the auto sizing to 'None' and minimize my cluster  to look like a straight line.

refer attached picture. I am not very sure if such sizing will help in this case.

[andrej]

I usually already use option to close all other VIs and make changes, but still it takes quite some time if the project is open. Closing project, changing cluster/control and opening project again will be even slower.

Usually I use "arrange vertically" option with clusters.

[Freelance_LV]

Hi

If your clusters are not on the GUI, then you could resize them all to look small and compact. they take up lot of size on the BD or the FP of the sub vis, when arranged vertically/horizontally.

could you post your cluster alone so that we can have a look? a vi usign this cluster might be more helpful.

[andrej]

Freelance_LV,

I'm not allowed to post it here, but I will use your advice.

I opened it with LV 2012 and it looks like there is no problem with performance anymore, so I will shift to LV 2012.