Saving Front Panel Defaults Programmatically

by David Thomson and Harald Stark

One question that appears frequently in LabVIEW discussion forums is, "How can front panel control values be saved automatically as defaults when the VI is done running?" It doesn’t take much poking around for one to find the VI Server method Make Current Values Default. However, many LabVIEW programmers have stumbled when trying to use this method, since it can only operate on a VI that is in edit mode, not run mode, and hence a running VI cannot execute this method on itself.

A fairly obvious solution to this dilemma is to have another VI call this method after the main VI has finished running. An example of this is even given on the Zone. (Search zone.ni.com for "LabVIEW AND defaults AND Server") Recently, Harald Stark at the NOAA Aeronomy Lab encountered a need for this functionality. In this article, we present the results of our refinements to the Zone’s solution. In particular, we incorporated some ideas from Kyle Gupton’s recent LTR article, "Cloning Front Panels" (LabVIEW Technical Resource, Vol 9, No 1). In addition to presenting an efficient method for cloning VIs, Kyle also discusses how to initialize a front panel behind the scenes by using the VI Server. By combining Kyle’s use of occurrences with the Zone’s example of Make Current Values Defaults, we are able to create an easy-to-use sub-VI that handles the somewhat tricky task of saving front panel values as defaults.

The diagram of an example program which saves its own defaults is shown in Figure 1. This VI, Example Program with Save Defaults.vi, writes random numbers over a specified range to a chart. If the Save Defaults option is selected, it calls the Save Defaults.vi sub-vi, which handles the details of using the VI Server.

Figure 1. The diagram of the example program. The details of saving the front panel defaults are encapsulated in the Save Defaults sub-vi.

In Figure 2, the diagram of Save Defaults.vi is shown. This VI uses the Call Chain function to programmatically determine the name of the VI whose defaults need to be saved. It passes this name, along with an occurrence, to the dynamically-called Save Defaults Core.vi. As discussed above, the Make Current Values Default method cannot be invoked on a running VI. The Save Defaults Core.vi is the solution to this problem, and the occurrence is a form of hand-shaking that ensures that the Save Defaults Core.vi is in memory and has a reference to itself before the calling VI stops. Since the Save Defaults Core.vi does not show its front panel (for a clean appearance and to prevent confusing the operator), it must obtain a reference to itself before the caller disposes of its reference to prevent LabVIEW from throwing it out of memory. This is the same technique that Kyle Gupton used in his Cloning and Initialization example.

Figure 2. The diagram for the Save Defaults.vi sub-VI. The name of the calling VI and the occurrence are sent to the Save Default Core.vi, which is then run with its front panel closed. Once the Save Defaults Core.vi sets the occurrence, this VI will stop.

The final part of the puzzle is the Save Defaults Core.vi, whose diagram is shown in Figure 3. This VI sets the occurrence to let the caller know that it is ready, then polls the caller using a VI Server property until it detects that the caller is no longer running. At that point it executes the Make Current Values Default method, then the Save Instrument method to ensure that the changes are saved to disk.

Figure 3. Save Defaults Core.vi diagram, which checks to see when the calling VI is done, then saves the default values.

There are a few caveats and limitations to this technique of which the user should be aware. First of all, the Save Defaults Core.vi and the Save Defaults.vi sub-VI should be in the same directory, since the Save Defaults.vi diagram assumes this when it calls the Save Defaults Core.vi. In addition, note that all the front panel controls and none of the front panel indicators are affected by this technique. There appears to be no way in LabVIEW to programmatically save a single control’s default value. It should also be noted that this technique will not work in built executables, since the LabVIEW environment for executables does not support the edit mode. Finally, it should be noted that this technique does appear to work when applied to a sub-VI that is used as a pop-up window for a higher-level VI. In our tests, even though the sub-VI is part of a hierarchy that is still running, when the pop-up window sub-VI finishes executing it is possible to save its front panel default values.

Several other methods are available for obtaining similar results. In particular, Stepan Riha discussed two techniques in "Remembering Control Values" (LabVIEW Technical Resource, Vol. 6, No. 3). The first of these uses the Configuration File VIs to save control values, with local variables used to read from and write to the controls as necessary.  The second method is simpler and more elegant, and uses the Get All Control Values and Set Control Value VI Server Methods.  This second technique is simpler in that local variables are not needed, and the programming is encapsulated in two sub-vi's: one to save control values at the end of a program, and one to restore them at the beginning. An advantage of both of these methods over the Save Defaults technique discussed here is that they work in executable programs as well as within the LabVIEW environment.  And although the second technique is fairly simple to implement, both are more complicated than the single sub-vi call of the Save Defaults technique.  Also, both of these other techniques create an additional file which must be maintained with the program, whereas the Save Defaults technique writes to the VI itself.

Despite the limitations, there are many situations where this technique may be useful. Hopefully, by packaging it as two easy-to-use VIs, the difficulty many have experienced in implementing this procedure will be largely removed.

About the authors:

David Thomson is a Research Scientist at the NOAA Aeronomy Lab, where he has been using LabVIEW for the last 11 years in the development of airborne atmospheric chemistry instrumentation. For the past 4 years, he has also been the principle of Original Code Consulting, an NI Alliance member (www.originalcode.com). Harald Stark is an atmospheric chemistry postdoc at the NOAA Aeronomy Lab. He started using LabVIEW in 2000 for controlling Cavity Ring Down Spectroscopy instruments.