SubVI and Global Variable

[S.Neo]

Hi,

I have a VI full of local variables and I was planning to clear up the block diagram with SubVIs. But I read that in SubVis there should not be any local variables and it must be changed to global variables. 

Just want to know if there is any other method to clean up my block diagram. I have attached an example of my block diagram. I would say  50% of the code consist of local variables.

Please kindly advice, thank you.  

[Bob_Schor]

Please attach the actual VI.  We can't edit a picture.  Without knowing the context of the "many local variables" you are using, it is difficult to show you the Error of Your Ways.

Bob Schor

[S.Neo]

I have attached the VI below. thanks

[MarcDub]

In general, it is recommended that local variables be limited to initialization and re-initialization of controls. Global variables should be used in a write-once / read-many approach.

The more variables you use, the more likely you will end up with problems with readability and race conditions.

I would recommend that you have a look at a state-machine and try to work out your problem using wires and shift registers. There is a state-machine template coming with LabVIEW since 2012 I think.

Take some time to rethink your architecture. Have a look at LabVIEW Core 1, 2, and 3 courses if you can. If you do it, your application will be more efficient, easier to maintain, and more likely to be used in the future.

[Bob_Schor]

Thank you for attaching your VI.  How do you expect to work with a block diagram that is 25,000 x 10,000 (my estimate) pixels in size?  It would take about a hundred monitors to see everything!

Of course, it was impossible to view much (I could see less than 1% of the BD in any one screen position), but I didn't see any (not one!) user-written sub-VI.  Sub-VIs are a great way to take an "ordinary screenful of code" (i.e. 1280 x 1024 pixels) and reduce its footprint to 32 x 32 pixels.  I have some pretty large programs, and less than 1% of my Block Diagrams is bigger than a laptop screen (and, then, only by 10%-15%).

Sorry I couldn't be more help, but it is just too difficult to navigate around your immense code.

Bob Schor

[S.Neo]

I find it difficult as well. Therefore I was thinking of cleaning it up. I am not sure if i can create subvi with local variable in it. 

[RavensFan]

Sure, you can create a subVI with local variables in it.  But local variables are another way to read or write to a control or inicator within that subVI.  They don't provide access to controls or indicators within other VI's.  If you need to use a value from the calling VI within a subVI, the proper way is to wire it in through the connector panel.  A secondary method is to pass a reference to a control into the subVI and wire that reference to a property node.  This is more ideal if you want a subVI to handle visual/property updates to a control in the main VI.  You can set and read values this way, but there are better methods.

Of course global VI's are a method to store a value that can be access from any VI.  But I've never really liked using them.  I believe I've used them only 2 or 3 times ever in my LabVIEW programming

[Bob_Schor]

You should not need a Local Variable in a sub-VI.  Suppose (as you seem to do a lot) you want to take a variable, increment it, and write it back to the same variable.  You are doing this (against advice) with Local Variables.  But in a sub-VI, you have "Value In" and "Value Out" connectors, which are different, so there's no issue.

To further save space, don't do one variable at a time.  Group variables together, either in Arrays or in Clusters (I prefer Clusters, particularly if you follow the recommendation to always create a TypeDef for your Clusters, as they allow you to name the elements and to "mix and match" various types), so a single wire represents many elements.

Ultimately, you should have "variables" being carried as wires in Shift Registers, with Controls possibly updating these Variables (and the Control's new value serving as the "Indicator" of the current value).

Bob Schor

[aputman]

I don't even know where to begin looking at this code.  I thought Bob was kidding about needing 100 monitors but he is not kidding.  No exaggeration. 

There is no defined order of operations.  There are portions of code that are repeated over and over again (this screams SubVI).  There is no documentation to explain anything.  There is no event structure.  There is no architecture to this code, whatsoever.  A state machine would probably be a good choice (I say "probably" because I have no clue what the program does and I got lost trying to figure it out). 

There is no reason that this code shouldn't fit on one monitor with no scrolling.  That should be your goal on all programs from the moment you begin coding.  If you, in a moment of weakness or laziness, say "I'll just put this code off to the side over here and come back to it later", that decision will snowball out of control and the only way to fix it is a complete rewrite.  I've seen it in others code and I've done it myself.  I've since repented and turned from that evil way.  I suggest you do the same.  

[WNM · Accepted solution]

Well it would be very simple to replace the circled portion of all instances of code like this with a subVI and you would not need to touch the local variables in the main VI:

Or, using control references to property (value) nodes, you could replace the circled portion indicated below with a subVI and the subVI would interface to the main VI controls through the link provided by the control reference.

But what you should be hearing from this discussion is that this VI needs considerably more help than what you are proposing to give it. It will still be too overgrown and too difficult to follow even if you push all instances of all block diagram primitives into subVIs. If what you have is already working or if you don't have much time remaining to get it working, then this can be daunting to start over using a new programming paradigm, but in the long run it really is the right thing to do just so it can be reasonably maintained.

Take a look at your front panel and start thinking about how you can combine commonly reoccurring groups of controls and indicators into small data structures (like a Boolean and a kW & kVAr) and then how you'd group those small data structures into larger ones (like HVAC or Lighting and then those into floors).  Define each of the the data structures using strict type definitions. Combine all the data structures into one big data structure which can be passed through the states of a state machine using shift registers. Then you are ready to use that state machine to read inputs, process the data, update outputs and repeat, always using the data contained in the data structure.