Generic method of saving configuration of Labview app.

[MichaelWestwood]

Hi,

I write numerous labview apps and one thing that plagues me is having to repeatedly rewrite the code to  load and save the configuration settings for an app. At the moment I create a comma seperated text file which contains all the data converted into string format. This is convenient because it the file is human-readable and I can label sections,etc. I've tried using the .ini file vis but that seemed to be more cumbersone to me. The nuisance is that I have to cast everything to strings, deconstruct clusters, etc when saving and then do the reverse when loading.

What I'd like to have in a perfect world is a generic vi that can easily accept a bunch of variables of any type, save them to a file in a coherent format and get them back again. My idea was to pass the vi an array of references. It could then iterate through and for each variable get the name and value, flatten the value using Variant to Flattened string vi and write these to a text file.

The two problems are :

1) One can't create a reference to a global that a property node will accept.

2) The flattened variant is not human-readable.

Any advice on this method or suggestions of a better way of doing this?

Thanks,

Mike

[falkpl]

The methods I have used for storing preferences/configs are:

1. Text files - easy to use, human readable but order matters

2.ini files - easy to use(not cumbersome once you get used to them), order in not important, extensible, human readable.  Labview uses these files often

3. Registry keys -  higher learning curve, can cause big problems if not used properly (this is a little bit of a taboo topic and scares off many novice users) big advantage is that the file is location independent and somewhat hidden from the user (could be a pro or con depending on the application).

4.  XML files - harder to use but there are a few flatten to XML functions.  This is platform and application independent, well structured extensible and a good option but requires a lot of planning to do right.

I prefer using .ini files usually.  Hope this helps.

Paul 

[becktho]

Hi

Just to add my point of view - I used to use ini-files. But always when a new value had to be inserted, I had to redo the vi, redo the connector and so on. After having a better support of xml-files under LV 7.0, I more and more now use xml-files. If the definition of the data to store changes, I just redo the typedef I use and that's it. I can modify the rest of the app in much less time.

The big advantage - they still are readable and, if necessary, changeable in a simple editor.

Thomas

[Jaegen]

I have also begun to use XML extensively, and agree that only needing to change the type def, and not the VI, makes maintenance a breeze.  My only issue now is this: XML files can't be incrementally updated to allow for changes to the type def.  i.e. If I change the type def, the existing XML file is no longer valid, and can't really be read at all, unless I go in and manually edit it in a text editor.  This means that configuration data for a previous release of my application can sometimes be totally lost when the app is upgraded.  Has anyone found a way around this?

Jaegen

[PaulG.]

I used to use ini files. I also inherited a rather large project that uses ini files extensively. Ini files can be quite cumbersome. Since I started getting familiar with XML in web pages I've started looking into using the XML functions in LV. I can't see any drawbacks. It looks almost too easy.

Paul

LV 5/6/7.1

2000/XP

[falkpl]

Jaegen,

Yes changing the data structure will pose a problem with the XML representation of the data (since the XML is a serialized version of the data structure) but there is a simple workaround that I have used, versioning your data.  That is place a version tag in the XML file, here you can use a case structure on the read vi to read data in a different format,  as long an the data structure can be converted in code, like unbundled a complex data type and rebundeling it to a new type.  Even a simple typecast will do sometimes.

Paul

[Jaegen]

So do you mean you keep an old copy/copies of the type def, and choose which one to use based on the version tag?  I was hoping to avoid having to do this.

[falkpl]

You would need old versions of the typedef but you could rename them, keep them in a separate library, devoted to reading/ writing XML files.  I haven't had to change my typedefs too much, but if you want to have your typedefs change with time and keep backwards compatibility then you might have little choice.  You could also not use the flatten to XML routines but develop your own schema for data storage, XML separates the syntax from semantics so this could be the best option.  The provided tools force you to use the NI schema but XML has endless possibilities.

Paul

[DFGray]

I usually use HDF5 for this purpose. It is a binary, hierarchical file API which produces completely cross platform files and generic browsers are freely available. A simple LabVIEW version is available from the article Can I Edit and Create Hierarchical Data Format (HDF5) files in LabVIEW?. Original source code, documentation, and file browser are available from the HDF5 website.

HDF5 does require some effort. There is no easy "flatten large data structure to string" method. However, HDF5 files are extensible; you can add to them at will, and they are fast. In addition, you can put a lot more than simple variables in them. For example, the NI-SCOPE Soft Front Panel (SFP) uses HDF5 for its configuration file. If the user has imported some waveforms for comparison into the SFP, when the configuration is saved, the user has the option to save the waveforms as well. If done, the waveforms are saved in the same file in binary, compressed form using the NI-HWS standard formatting (NI-HWS is HDF5 based). A link is put in the configuration pointing to the waveforms. The waveforms also contain a link back to the configuration, so that if a user imports the waveform into the SFP and wishes to reset the SFP to the configuration present when the waveform was taken, this can easily be done. Those who have been paying attention will notice the circular reference. This is possible because HDF5 is actually a directed graph, not a hierarchy.

Some generic tips for configuration files, some of which have been mentioned

• Always put a version number in your config file. This is the version of the configuration format, not the version of your software. That way you will always know how to read it.
• Never use flatten to string to save things. Experience has shown that the format usually ends up lost, along with the data.
• If you use a text format, make sure you save enough digits for floating point values. This is a large problem for the LabVIEW flatten to XML code, which uses a fixed number of digits (six, I believe).