Converting 600+ Locals to Cluster Shift Register

[DL84]

Back for a bit more advice,

I've been getting some advice on fixing up a massive program that I took over awhile back.  Basically I told my boss that the future plans we had for our test program were not possible until resources were opened up that were unnecessarily being taken up by the existing program.

Locals seem to take one of the hardest hits on this forum, the training classes, and even at the NI symposium....well this program when everything is running, uses 600+ variables used as both controls/indicators.  Correct me if i'm wrong  but the way to go would be one massive shift register running through the state machine program containing all of these controls/indicators.  Each state I'd then have 1 unbundle by name, and 1 bundle by name to handle all of the reads/writes.

If thats correct, i've tried to start this up but i'm having trouble moving controls into the cluster....would I need to delete all the locals associated with that variable first?

Also, is 1 big shift register the way to go, or several?  How would you break the clusters up if "partitioning" them off?

One more....when running I've got the program using about 38% of the CPU at full load....after getting this switched over....would the effeciency boost drop that very much you think?

Thanks for the input!

[DFGray]

The approach you take should be dictated by how you can easily maintain the code.  I, personally, like to use an object-oriented approach to data.  I group the data into logically related chunks, create reference objects for each chunk, and include the methods (VIs) that work on that data in the same directory/project folder.  I don't typically use shift registers because they require you to feed data through multiple subVIs to get to where the variable is actually used (you do use subVIs, don't you).  Reference objects get around this issue at the cost of being careful to avoid race conditions.  However, a single shift register wire with hierarchy created by using clusters of clusters is also an efficient way to store and use your data.  A single flat cluster will be hard to maintain for 600 variables.  If you have LV8.2 or higher, consider using a cluster of LV Objects as your shift register.  This gives you real object-oriented design, as you get both data and methods for your objects.  Each object contains a group of logically connected variables.

Performance may or may not go up.  It depends on where your bottlenecks are.  Reading and writing a shift register is an order of magnitude or more faster than reading and writing locals.  But your bottleneck may be in IO or UI.  Do you use an event structure or polling for your UI?  Changing from polling to an event structure will probably give a boost in performance.

Good luck.  You are on the right track by trying to eliminate locals.  You can find out more about reference objects by searching this forum for "reference objects", "action engine", "LabVIEW 2 global", "functional global", or "single element queue".  A search for application design patterns may also be useful.

[unclebump]

If you have the DSC module, you might want to look at saving the data into internal memory areas. Then you just read/write the values and would not need the shift register. A benefit of this is having the Citadel database to log historical data.