Programming Configuration Files in LabVIEW

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

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: • Basic • Easy-to-Maintain Version • Automated using Control References • 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