Parsing logger responses

To implement robust automated parsing of responses to logger commands, there are some important points to consider.

• Do not assume the upper-case/lower-case nature of the responses will match those in the command.  For example,
  

  CODE

  >> MEMINFO USED
  << MEMINFO used = 0

  It is good practice to make parsing insensitive to the case of the responses.
  

• Do not assume that parameters will be reported in the same order they were requested.  For example,

  CODE

  >> meminfo size used remaining
  << meminfo used = 0, remaining = 132120576, size = 132120576

  It is good practice to check each <key> = <value> pair for the <key> of interest until all searches are satisfied.

• Be aware that future versions of the instrument firmware may report parameters that are not documented here, and that the reporting order may change.  For example,
  
  
  

  CODE

  >> meminfo
  << meminfo used = 0, remaining = 132120576, size = 132120576

  
  

  is the current behaviour, but a future version might respond as follows:
  

  CODE

  >> meminfo
  << meminfo used = 0, remaining = 132120576, futureparameter = 132120576, size = 132120576

  Again, it is good practice to check all <key> = <value> pairs, and be prepared to ignore <key>s which are not recognized.
  

• Do not assume that numeric fields will always have the same number of digits.  Even parameters whose values might be expected to remain fixed can change if the logger is used in a different configuration.  For example, an instrument with an auto-ranging channel might behave as follows:
  

  CODE

  
  >> channel 4 gain
  << channel 4 gain = auto
  
  >> channels readtime
  << channels readtime = 1890
  
  >> channel 4 gain = 20
  
  << channel 4 gain = 20.0
  
  >> channels readtime
  
  << channels readtime = 350

  
  This is true even when parsing data values with a well specified format.  For example, even though reporting of values may be specified to contain four decimal places (eg. 21.7325), parsing this number without assuming anything about how many digits there are is more robust.

• When parsing streamed output or fetched values, it is good practice to assume some channels might report error code (see outputformat and fetch). If a channel report an error code, others channels might still be valid.

• When parsing numbers of any sort, use the most inclusive format which is practical.  In principle, parsing everything as a double precision floating point number would almost always work (one exception being the 64-bit integers used for timestamps in EasyParse format: see the paragraph "Sample timing" in Section "Sample data EasyParse format").  Recognizing that such an approach is overkill and may add unacceptable overhead in some applications, parsing all integers as signed 32-bit quantities and all floating point values as single precision (IEEE-754 32-bit) numbers would be satisfactory.  It may be assumed that numbers are integers unless the documentation or examples make it clear that they are floating point values.
  

  Note that some commands accept and respond with date/times which look like very large integers, but which have an implicit special format.  For example, 20170401120000 represents noon on 1st April 2017. These cases are usually clear from the context.