is it a good idea to keep code clean with (huge) custom control?

[Frank_Mathijs]

I have a typical structure in my program: Acquire, preprocess, data-analysis and saving. For the data analysis, we have four possible methods, each with its own parameters (some parameters are arrays of 500 elements and more). When i arrived at this job, they had a program with only one of those analysis methods implemented, and it was a mess, lots of wires going everywhere. So, with the little labview knowledge i had, i proposed to make a (very) big custom control with all the parameters and by bundling and unbundling by name, i can read and update all the necessary parameters. is this a good strategy? will this have a serious impact on the programs performance?

[johnsold]

I do exactly what you have described. It seems to work well.

Use a shift register or action engine to pass the data around to minimize the number of copies made.

Lynn

[andre.buurman@carya]

I agree with Lynn on the use of action engine for storage, but additionally I would like to suggest to split the data up into multiple action engines. Each parameter set in its own action engine. This will improve the readability of your code in my opinion.


Message Edited by andre.buurman@carya on 12-11-2007 03:24 PM

[Frank_Mathijs]

I'm sorry, i don't really know what action engines are. Now, i have a while loop with that big cluster going in a shift register, and in the loop all the subvi's take that cluster as an input, they use the data, update and put it as an output again. at the end the big cluster goes in the shiftregister again. Is that what you are talking about, or maybe the exact opposite 🙂 ?

[Gabi1]

check it here

i use exactly this strategy. i am a big lover of clusters. the big advantages are:
- adressability of every single element via reference
- using bundle and undbundle by name allows for very efficient self documentation (if you label all your controls), on top of very clean coding.

But: try to keep clusters limited in nb of different elements in. i would be carefull doing cluster of cluster of cluster (more than a hierarchy of 2 is difficult to manage).
also, i cant stress enough how efficient are Action engines for transfering cluster info, on top of encapsulation of the cluster.

also: use clusters only as type def. you will often have to create constants, indics, unbundle...in several subvis. keeping in a typedef allows to update the cluster in all instances at the same time.

[Frank_Mathijs]

Thanks for the answers! As i'm only reading and writing data (settings and updated averages), should i just make functional globals to read and write every 'sub'-cluster?

[Frank_Mathijs]

Sorry for replying to my own post, i couldn't find an edit option... I just wanted to make sure i'm going in the right direction. I have included a jpg of my vi's structure. the pink wire is the big cluster i posted earlier. If I understand Labview, it now makes a copy of the data everytime I use that cluster as an input (because everytime it is used as an input, there is a frontpanel) ... and when i use a non-reentrant FG, the data stays in one and the same memory location? thus improving performance of my VI? Correct?

[andre.buurman@carya]

Seems OK to me.

The splitting up part is only interesting from a performance point of view.
When mulitple appliaction parts need different information at the same
time they now have to wait unitl the other has read the data, with split
data they have there own VI's to call, hence no wait.

[Gabi1]

NI representatives will make better comments than i do, yet:

in general if you do not open the front panel of the subvis, there will be no actual copy of the data in it (certain rules apply tough, depending what is in the subvi, and if the control is in the main frame or in a structure).

however if your subvi is reentrant there might be a copy. it doesnt seem to apply in your case, unless you do some recursive treatment.

one thing tough: to my taste your cluster is too big. are you sure you cannot separate it in few clusters, each with its own shift register and subvis? a subvi can have several clusters as input for specific interlacing treatment of data.

[Frank_Mathijs]

At first, when I made the cluster, my only concern was improving readability of the vi. Later, my bosses wanted more and more options, so the cluster grew and I started wondering about performance, and looking for other options, like FG's.
In my case, the subvi's don't open when called, so maybe i don't have to change to FG's.
And if the size of the cluster is only an esthetical problem, that's no problem as well, setting the parameters is done in an initialisation phase, after that, the user doesn't need to see that (horrible) cluster.