Does a large amount of "local variable" within a vi cause problems?

[NewMachine]

Hello -- I am using Labview 7.0 and have a vi where I am going to end up using about 100 "local variables" for indicators that are displaying data. Since I have a lot of true / false case structures I decided to use these local variables instead of having a mess of wiring all over the vi block diagram. It is intimidating though and I was wondering if it causes slowness in vi's?

[johnsold]

Local variables are slightly slower than direct wiring, but still much faster than display updates. The real problem with local variables is the difficulty of seeing what is going on because of the "breaking" of the dataflow paradigm.

Do you have 100 indicators or a much smaller number which you update from several places each? Either way, there may be better approaches to what you are trying to do. Can you post a simplified version of your VI so that we can look at it an offer suggestions.

Lynn

[NewMachine]

I actually only have about 8 indicators -- but I am in the process of creating control algorithms so I have to use many case structures if I want to keep the code all within Labview (simplicity). I am simply referencing the 8 or so indicator values many many times (100 X) I am attaching a copy of the vi like you asked but just take a look at the right hand side of the while loop on the right -- it shows an example of an algorithm I created today that has to reference the data from sensors. I would love to know what a better way to do this. Thanks!

[johnsold]

I have not had time to study your VI yet, but it looks like an ideal candidate for a state machine architecture. Look at the examples and search for "state machine" in the archives.

The state machine architecture is versatile and robust. It is widely used for control systems such as yours.

Communicating between the independent loops is often done with queues. A main loop with an event structure handles the user interface (UI) and passes commands and data to the processing loops. In return they pass status and data messages to the UI. All without local or global variables.

Each parallel loop should have a wait function, even if set to zero milliseconds. This will allow LabVIEW's internal scheduler to switch between loops and keep one of them from hoggin all the CPU time.

I'll try to take a more careful look later, but these comments will give you some things to think about.

Lynn