Programming Configuration Files in LabVIEW

1
Programming Configuration Filesin 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
• 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