1. Programming Configuration Files in LabVIEW David Thomson Systems Integrator Original Code Consulting National Instruments Alliance Member Research Scientist NOAA Aeronomy Lab

2. Configuration Management ● Ideally, a project is completely designed before any programming begins ● In (my) reality, the software must often evolve as hardware is developed ● In order to maintain flexibility, many parameters are stored in a configuration file rather than hard- coded ● How can these configuration parameters to stored and managed as the project evolves?

3. Configuration File Methods in LV ● Save front-panel defaults ● Binary files (write a cluster or clusters of parameters directly to a file) ● Save parameters in the Windows Registry ● Use the Configuration (.ini) File VIs ● Other ideas?

4. Save Front Panel Defaults ● Useful for small programs that don't need much configuration management ● Use VI Server ● Does not work in built executables or on running VIs ● See “Save Defaults” at www.originalcode.com for a simple implementation

5. Binary File (Single Cluster) ● Wire a cluster of parameters directly to the Write File primitive ● Very simple to implement ● Limited to a single cluster ● Can't write different cluster types to the same binary file ● Extremely large clusters can excede LabVIEW's capacity ● Hard to maintain as parameters are added ● Old files can not be read once the cluster has changed

6. Multiple Clusters ● If the number of parameters excedes the capacity of a single cluster, write multiple clusters to a binary file ● Flatten each cluster to a string ● Prepend the string with a flattened string containing the length of the cluster string ● Multiple strings can be written, then read by first reading the string length, then the clusters unflattened

7. Multiple Clusters ● Very difficult to maintain as the parameters change ● Fairly convoluted diagram for reading and writing the clusters

8. Saving to the Windows Registry ● LabVIEW VIs are provided for reading and writing registry keys since LV 6.0 ● No examples provided here ● There is inherent danger in messing with the registry ● This has been discussed extensively on Info- LabVIEW (search the archives)

9. Configuration (.ini) Files ● Since LV 5.1, there have been VIs for reading and writing.ini files ● Improved significantly (polymorphic) in recent versions ● Creates human-readable files ● New keys can be added at any time ● Old keys can be ignored ● Can handle default values for missing keys

10. Configuration (.ini) Files ● Four variations presented here: 1)Basic 2)Easy-to-Maintain Version 3)Automated using Control References 4)Automated using Variants

11. Basic Configuration File ● Diagram is simple, but gets big fast ● Cluster names and key names contain redundant data ● Can automatically create the configuration file the first time using the default values ● **Must make sure the writer and reader are always synchronized with each other when parameters are added or changed**

12. Easy-to-Maintain Config Files ● Developed by David Thomson and Scott McLaughlin (formerly of NOAA ETL, now with Applied Technologies) ● One VI that reads and writes ● Eliminates problems synchronizing names in two VIs ● Wrap the polymorphic Config VIs into a polymorphic Read/Write VI ● Case structure makes the diagram more managable

13. Easy-to-Maintain Config Files ● Use of Type-def Enum and Unbundling techniques add automatic error checking when more parameters are added ● Can automatically parse cluster and parameter names to generate section and key names

14. Automated using Control Refs ● Developed by Jim Kring ● see www.openg.org for more information ● Uses the Control Ref for the cluster to parse the parameters, using labels for Section and Key names ● No new programming needed when new parameters are added (assuming flat clusters or arrays of clusters)

15. Automated using Control Refs ● Default values are handled differently ● Other structures not yet implemented would have to be programmed ● Clever implementation, but now supplanted by the next example

16. Automated using Variants ● Developed by Jim Kring and Jean-Pierre Drolet ● See www.openg.org for more information ● http://sourceforge.net/projects/opengtoolkit for downloads ● Requires additional toolsets from OpenG ● Converts the main cluster to a variant, then parses the variant header ● Calls itself recursively to parse any arbitrarily complex structure

17. Automated using Variants ● Automatically handles writing any data structure with no programming ● Includes handling of default values ● Recently improved to better handle complex data structures ● Arrays are a special case ● Default values for arrays are handled differently than for other data types ● The number of elements read is determined from what is in the file, not by the default array supplied

18. Final Caveats ● Good practice requires that all elements in a cluster and in each sub-cluster have unique names Especially important when saving clusters to.ini files, as elements with duplicate section and key names will only appear in the file once