local variable without frontpanel object

[kahei]

is there a possibility to create local variables without the need of a frontpanel object? I need zhem for program ccontrolontrol but don't want to show them to the user.
Thanks a lot,
greetings from Germany
Karin

[isharryf]

Create a front panel object and permanently hide it.
This can be done by using the atrribute visible; set it false in your initialisation routine.

[EdDickens]

Another option that really doesn't use a front panel object would be a subvi with an uninitialized shift register in a while loop and a case structure to either read or write to it. These are known as LabVIEW 2 globals or functioal globals.

I have attached an example of a simple one. Of course you'll need to change the numeric control to match your data type.

Save a copy of this with a descriptive name for the data, then use it where ever you would the variable and specify the needed action.

Do not make this Reetrant or it will not work.

Ed

[altenbach]

Just righ-click on the terminal of the control and select "hide control".

[gnunesjr]

This is an old topic, but I would like to hear from the experts whether Ed Dickens' solution to this issue is still considered best practice.

I have a big, complicated program that controls and records data from several pieces of equipment at once.  I have about 100 variables that are used to hold settings and to allow the various parts of the program to communicate with each other.  The user does not need to see these, and there is no need for them to be front panel objects.  I have already had one very ugly incident in which my LabVIEW code became corrupted and a good portion of the screen would not update.  Telephone support informed me that this kind of behavior has been linked to "too many indicators" and that hiding them does not help.  I guess it's kind of like having "too many notes"....

As I said before, I would be happy to keep all this information in "internal variables," as I would do in a text-based programming language (where I would also not have the "your source code compiles and runs but is deeply corrupted and unrecoverable" problem...).  I just want to make sure, before I go through the hard labor of creating 100 additional sub vis, that I will actually be moving my project away from the problem and not towards it (or some other bit of nastiness).

[johnsold]

This has been discussed several times. Wires area always the best way to pass data from one place to another.

If you don't want 100 wires, you can group them into one or more clusters. If you have parallel processes which cannot use wire because of dataflow, functional globals or queues are good choices. Both of these can also use clusters as the datatype.

One adavantage of having a control is that by making it a tyepdef, then any changes need only be made at one point - the typedef - and they will propagate throught the program. If you create the typedef control, you can create a constant from it nad then delete the control. The control file "xxx.ctl" will be loaded but the control does not have to be on the panel.

Lynn

[Marc_A]

Before you go creating 100 different LV2 globals for everything you want to store, you should think about alternate methods. First, shift registers are the fastest method to store data in a running program. Also, using clusters to store like data will save you a lot of time, especially since you said all of your hidden controls are for settings. For most of my settings that users set in a dialog but don't need to see all the time, I use a config file to store values and a typedef cluster to hold them in the program. The file gets read at appropriate times and the cluster is updated. When I need a specific setting, I unbundle the cluster from the shift register and read whatever data I need.

You really only need LV2 globals to exchange data between VIs that are running side by side dynamically and aren't connected by wires as in a main-subvi relationship.

Edit: Lynn beat me to most of what I had to say. Good info there, I hope all this helps.

Message Edited by Marc A on 02-27-2007 04:59 PM

[tbob]

If you use a state machine, one case can be used to define all your local variables, without using indicators.  They can be all bundled together.  In other states, you can unbundle to get the values, change the values and then bundle to store the new values.  See simplified attached vi.

[gnunesjr]

Lynn, Marc, and "tbob",

Thanks for your replies.  I detect the common theme of keeping my variables in bundles, but I'm not experienced enough to see how to apply this to my problem of communicating between parallel event handlers.  If you have the time and patience, I have attached a very simple example of what goes on in my program.

I have three independent systems:  a motion system that carries around a microscope and digital camera.  Each system has its own event handler.  The motion system responds to user commands to move the microscope around, the microscope handler responds to changes in focus, zoom, etc, and the camera event handler continuously snaps pictures to provide a "live" image.

But sometimes the loops need to talk to each other. For example, autofocusing is handled by the camera event handler, because it is based on image contrast, and that is the event handler that is acquiring the images.  So that means the camera event handler should take over the microscope during auto focus.  So the microscope event handler needs to be prevented from trying to get in on the act.

So here is what the example illustrates:  some motion has just ended "normally".  The timeout event in the motion system signals the camera system to perform an auto focus (and waits for the focus to complete before allowing any movement).  The camera system signals the microscope system to perform a "stop" event, does the auto focus, releases the microscope from the stop event, and signals back to the motion loop that auto focus is done. 

I, of course, thought this kind of thing was very clever!  More experienced Labviewistas may have other opinions....

-Geoff

[gnunesjr]

I submitted that last post one "save" too soon.  The (obvious) correction to the example is here.

-Geoff