Read parameter files

[buddyfares]

I am looking for the correct way to read in parameter files and then use within program to set say test limits and such instead of hard coding. I have done this in VB and stored the values in constants or variables.  Looking for the best practice way in LabVIEW.

Any help appreciated  

[RavensFan]

What exactly do you meany by "parameter files"?  I hear "parameter" and it makes me think of "configuration".

Look in the palettes for Read and Write Configuration files which allows you to write values out to a human readable text file.

[buddyfares]

By parameters I would mean things like test limits, nominal values, text strings that would describe a test or condition.  So instead of having these limits hard coded in compare statements they would be read in and assigned during program execution. Say I want to measure 5 volts with limits of +- .1.  If the value or limit would change I would just want to edit a text file and would not have to recompile the program.

I think reading in the file is pretty straight forward and so is parsing it but how do I assign the values to equations or other constants in the program. is it best proactive to read in the file once and assign all the values or read and parse as needed?

[RavensFan]

Of course read the file in at the beginning.  Assign the values to one or more clusters that you store in a shift register that you can then unbundle and use whenever you need.

Another good configuration file VI library is MGI's Read Write Anything you can find on JKI's VI Package Manager.  With that, you can create a cluster as a typedef and just tell it to read it from the file, or write it to the file and it does all the work of reading and writing to your LabVIEW datatype.

[Bob_Schor]

There are many ways to handle "Parameter files" (or "Configuration files").  One common pattern is to gather all of the Configuration Data into a single Cluster, saved as a TypeDef (so its structure is known and relatively fixed), organizing the various Data elements in a way that "makes sense for you".  You can then write a single VI to Read/Write this Cluster to a file, or write a pair of VIs, one to read and one to write.  The virtue of this scheme is that it is defined by the Cluster, making it easy for you to write a "Template" that is guaranteed to (a) be "Human-readable" as a text file, and (b) be correctly "parsable" when read in by your "Read Configuration" VI (as long as you don't violate the formatting of the file by moving parameters around, changing their spelling, etc.)

One form of a Configuration File that has been around for a while in Windows is the ".INI" file (introduced in DOS, I believe).  NI has a set of functions specifically for dealing with INI files.  One takes a filename and opens the file for reading or writing, returning a Reference to the file, and another takes that Reference and closes the file.  These two functions are the only ones that do File I/O -- Open reads in the entire .INI file, ready for parsing, while Close writes the entire file back to disk.

The Config File elements are written in "Section, Key, Value" form, explained nicely in the LabVIEW Help.  Look at the detailed Help for Open Config Data which contains a link to "Windows Configuration Settings File Format" (the link name in LabVIEW 2018 is "Format the content" (found right at the top of the Detailed help).  You need to make up Section and Key names for each of your Cluster elements.  The Cluster can have Array components -- you just need to make up "internal Key names" (such as "Val 0", "Val 1, "Val 2") for each Array name (as the INI format only accepts single String, Path, Dbl, I32, U32, or Boolean components).  This lets you "sneak" Arrays into your Cluster (and hence into your Configuration File).

Create the "Write INI File" VI first.  Feed it your Cluster that served as a template for the code you used for the INI file, and it will write the file for you.  You can now create Read INI File by simply replacing all of the "Write Key" functions with "Read Key"..

Other formats you could use for a Configuration file include XML, JSON, or just plain text.  The advantage of more "structured" formats is it allows you to go from a Text File directly into a LabVIEW-style data structure (such as a Cluster).

One thing I didn't explicitly answer (but hoped you "got") was most of these schemes are "Read the entire configuration in all-at-once, parse all at once, and retain as a Wire on a Shift Register".

Bob Schor

What I do is to use Cluster element names for "Section", 

[buddyfares]

One more quick question.  I am sure I should know this but drawing a blank!  When I wire to the shift register of a state machine to make the param accessible to the parts of the program that is needed do I need to wire the data through each state to make it available to the next state or is there a way just to wire to the input register and the data would always be available there?

[RavensFan]

Do you ever have the need for a state of your state machine to change the values in the cluster? (Think of a state that lets the user edit the data to change a value, and possibly re-save it to a file.)  Then you will want to have the wire go into and through all states.

If the file is only read once prior to the start of your state machine and you never change the data, then you can avoid the shift register and just wire from a regular tunnel into whichever states actually need access to the data.

[Bob_Schor]

Several paradigms in LabVIEW (such as State Machine, Queued Message Handler) consist of a While Loop with a Shift Register holding "variable" (such as Configuration Data, often a Cluster) and, inside, a Case Statement that lets you handle multiple "States" (for a State Machine) or multiple "Messages" (for a Message Handler).  The Shift Register is assumed to hold data potentially needed by all the Cases (though some may ignore it, some may read it, some may create it, some may modify it).  

For this to work, you need the Shift Register's "Wire" to enter and exit every Case, so Left SR to left Case Tunnel to right Case Tunnel to right SR.  A "trick" to simplify creating all the Case "Wire across from In to Out Tunnel" is to right-click the Right Tunnel and choose "Linked Input Tunnel", then choose "Create and Wire Un-wired Cases", which will add wires to all the unwired Case Tunnels.  If you do this, as you add Cases, they will also "auto-wire".  Note you can break any of these wires if you need to "extract" data from, or "insert" data into, the wire.

Bob Schor