C scan

From Applied Optics Wiki
Revision as of 13:39, 31 July 2012 by Matt (talk | contribs) (Created page with "C_SCAN(1) User Manuals C_SCAN(1) NAME c_scan - modular hardware control and data acquisition utility SYNOPSIS c_sc...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

C_SCAN(1) User Manuals C_SCAN(1)


NAME

      c_scan - modular hardware control and data acquisition utility

SYNOPSIS

      c_scan con-file.con

DESCRIPTION

      c_scan  is  a modular hardware control and data acquisition utility. It
      is configured using a con-file(5) which describes a set of  actions  to
      be  performed. Each action usually describes a specific task to be per‐
      formed, usually by a specific piece of hardware. However it is possible
      for  a  task not to involve any hardware at all (e.g. waiting for a key
      press), it may involve several tasks for a specific piece  of  hardware
      (setting  up  the parameters of a signal generator) or it may involve a
      specific task involving several pieces of hardware  (performing  higher
      order aberration correction).
      Some  or  all  of  the actions can incorporate loops, whereby a certain
      parameter is changed over a certain  range  (e.g.  the  position  of  a
      mechanical stage, or the frequency of a signal generator).  These loops
      are referred to as scans.  Where an action  includes  a  scan,  further
      actions can be performed either at each scan step or after the scan has
      been completed...  see con-file(5) for further details.


OPTIONS

      There are no options to c_scan, other than specifying the con-file.  If
      c_scan  is  called  without an argument or an invalid con-file, it will
      report the hardware modules that have been compiled  into  the  utility
      and exit with an error about a missing con-file.


DIAGNOSTICS

      The  utility  incorporates  a  signal handler, this catches any signals
      (such as keyboard interrupts, segmentatation  faults  etc.)   and  pro‐
      cesses  them in an appropriate way. This is because many of the modules
      involving pieces of hardware write information about their current sta‐
      tus  to  disk, to retain information about their physical state between
      power-offs. This information must be written to disk  before  the  pro‐
      gramme terminates.


BUGS

      Probably many and varied. See individual actions for specific bugs.


AUTHORS

      Matt Clark <matt.no.spam.clark@no.spam.nottingham.ac.uk>
      Steve D. Sharples <steve.no.spam.sharples@no.spam.nottingham.ac.uk>


SEE ALSO

      con-file(5)