Persistent variables in Labview

[Graybeard]

Is there a way to make a variable persistent from one execution of a vi to the next?  That i, if I change a variable during execution of a vi, will it retain the new value the next time I execute it, or will it default to something else, or will it be undefined? Labview & the vi will be unloaded between executions. Thanks.

[mikeporter]

There's not a way to do it automatically, but you can program the behavior. Before the VI stops save the values of the variables to someplace convenient (like a custom key in the ini file or a file of your own creation) and then when the VI restarts load the values back into the variables.

Mike...

[Graybeard]

Thanks Mike.  I kinda hoped to avoid the file I/O method, but if that's what I need to do...

'...a custom key in the ini file ...'

can you expand on this? or point me to a doc that talks about it?

Thanks in advance...

[mikeporter]

LV ships with VIs for writing to ini files in a structured way. In other words, you define the section and key labels and you can read or write the associated value. I would recommend the application ini file because its always easy to find and it's always there. They are located in the Configuration File VIs submenu under File IO menu.

Mike...

[DFGray]

If you are running on Windows, you can use the Window Registry for the same purpose.  Those VIs can be found in Connectivity->Windows Registry Access VIs.

I would recommend the INI file VIs, since they are somewhat easier to use and are platform independent.  If you store floating point, make sure the resolution is high enough.  An INI file is a text file.

If you want persistent storage on steroids, you can use the HDF5 solution.  This allows complex data structures and massive data sets to be persisted.  NI has never officially supported this externally, but you can get an older API here.  Some of the forum members have written newer ones.  You can find these by searching this forum for "HDF5".

Finally, you can roll your own, since LabVIEW has a complete set of low-level file I/O tools.  If you only have a couple of items, this may be your best option.  However, it is the hardest to maintain and modify in the long run.

Let us know if you need more help or information.

[craigc]

Just a thought i have never used it but it may be worth a look is the "Make current values default" Invoke node.  Open a VI reference to the panel where the controls / variables are, and then use an Invoke node to set the present values to default before closing the VI down.  The only thing is that you will have to save before you exit etc etc.

As i say, i have never used them personally but may be worth a look.

Craig

[Graybeard]

Thanks all for your input.  I only have a few variables I need to maintain, so I'll probably go with the INI file method.  I found several examples to point the way.

[mikeporter]

There are file formats that support more complex data, but if you are going to go to that extent it would probably be just as easy to go the whole way and put a database in the system. The tools for doing this are (as I like to say) free - both economically and philosophically - and it's really not that hard to do.

If you have a very limited number of items programatically setting the default values for controls can be done, but in practice can get kind of tricky at times. There have been numerous threads on this in the past.

Mike...

[rolfk]

---

@craigc wrote:

Just a thought i have never used it but it may be worth a look is the "Make current values default" Invoke node.  Open a VI reference to the panel where the controls / variables are, and then use an Invoke node to set the present values to default before closing the VI down.  The only thing is that you will have to save before you exit etc etc.

As i say, i have never used them personally but may be worth a look.

---

This doesn't work well for runtime defaults. "Make current values default" is an edit only operation, that means the VI you want to invoke this method on can't be running nor reserved for running. So you would have to have another independant VI that takes over, waits until the original application has stopped executing, then invokes that method in the VIs inside the original application, and also then invokes the safe method for those VIs too, but the safe method is not operational in the runtime engine. So all in all a very complicated exercise that does not even work in an executable.

Go for INI files! Registry is a possibility but you should really know what you do when doing something with the registry and it is also a Windows only feature so why limit yourself here if it is not necessary.

Rolf Kalbermatter

[craigc]

Hi Rolf,

Thanks for the answer, always good to shed some light on all the angles.  As i say i havent used the "Set current value to default" and it looks like i probably never will now.
Craig