Control Commands: Difference between revisions

From EOVSA Wiki
Jump to navigation Jump to search
(Created page with "Updates: * GN: 2013-Jan-13: Introduced new commands related to the Hittite synthesizers: FSEQ-SCRIPT; LO1A-WRITE; LO1B-WRITE. Added subarray arguments to all FSEQ-* commands...")
 
No edit summary
Line 1: Line 1:
Updates:
<span style="color: red;"> EOVSA Control Language (Draft 2014-Apr-28)</span>
 
* GN: 2013-Jan-13: Introduced new commands related to the Hittite synthesizers: FSEQ-SCRIPT;
 
LO1A-WRITE; LO1B-WRITE. Added subarray arguments to all FSEQ-* commands.
 
* GN: 2013-Jan- 16: Added a System Recovery Procedures section to this document.


Updates:
*GN: 2013-Jan-13: Introduced new commands related to the Hittite synthesizers: FSEQ-SCRIPT; LO1A-WRITE; LO1B-WRITE. Added subarray arguments to all FSEQ-* commands.
*GN: 2013-Jan-16: Added a  System Recovery Procedures section to this document
The Schedule program needs to send commands and information to the Array Control Computer (ACC) in order to specify antenna pointing coordinates, tuning, and other system parameters that will change from scan to scan and for different modes of operation (e.g. calibrations of various types, normal solar observing, etc.).  This document specifies a command language to accomplish this task, with commands at two levels: (1) High-level commands (macro-commands) that accomplish standard operations in a human-readable form, and will mainly be specified in the top layer of the schedule, and (2) atomic commands from which such macro-commands are constructed, that provide flexibility in defining the order and duration of discrete tasks.  Examples of macro-commands would include a SOLPNTCAL command, which initiates a pointing procedure that does multiple offsets of the antennas and takes data that will be analyzed for determining frequency-dependent pointing offsets.  Examples of atomic commands would be DATA-ON, which starts data recording, or DOSEQ, which initiates a tuning sequence.  The schedule will contain macro-commands associated with files of the same name, e.g. the SOLPNTCAL command would be associated with a file named solpntcal.ctl, which contains a list of atomic commands to execute the SOLPNTCAL.  These atomic commands are what will be executed (either locally or by sending the command on to the ACC).  It is expected that the ACC will return from receiving an atomic command immediately, and if a command takes some time, the ACC will store and execute the commands in the order received.  The currently running atomic command will be indicated in the stateframe, and the Schedule program will examine the stateframe to determine when an individual atomic command is completed.  The stateframe will also include the macro command currently being executed.  This draft document specifies that both macro- and atomic commands be given as ASCII text in UPPER CASE in the stateframe.  It can be typed in lower case in the schedule, but will be converted to upper case prior to display and transfer to the ACC.  Although the macro-command will be sent to the ACC, typically this is for information only (for writing into the stateframe), and the ACC will act only on the atomic commands.
The Schedule program needs to send commands and information to the Array Control Computer (ACC) in order to specify antenna pointing coordinates, tuning, and other system parameters that will change from scan to scan and for different modes of operation (e.g. calibrations of various types, normal solar observing, etc.).  This document specifies a command language to accomplish this task, with commands at two levels: (1) High-level commands (macro-commands) that accomplish standard operations in a human-readable form, and will mainly be specified in the top layer of the schedule, and (2) atomic commands from which such macro-commands are constructed, that provide flexibility in defining the order and duration of discrete tasks.  Examples of macro-commands would include a SOLPNTCAL command, which initiates a pointing procedure that does multiple offsets of the antennas and takes data that will be analyzed for determining frequency-dependent pointing offsets.  Examples of atomic commands would be DATA-ON, which starts data recording, or DOSEQ, which initiates a tuning sequence.  The schedule will contain macro-commands associated with files of the same name, e.g. the SOLPNTCAL command would be associated with a file named solpntcal.ctl, which contains a list of atomic commands to execute the SOLPNTCAL.  These atomic commands are what will be executed (either locally or by sending the command on to the ACC).  It is expected that the ACC will return from receiving an atomic command immediately, and if a command takes some time, the ACC will store and execute the commands in the order received.  The currently running atomic command will be indicated in the stateframe, and the Schedule program will examine the stateframe to determine when an individual atomic command is completed.  The stateframe will also include the macro command currently being executed.  This draft document specifies that both macro- and atomic commands be given as ASCII text in UPPER CASE in the stateframe.  It can be typed in lower case in the schedule, but will be converted to upper case prior to display and transfer to the ACC.  Although the macro-command will be sent to the ACC, typically this is for information only (for writing into the stateframe), and the ACC will act only on the atomic commands.
==List of Atomic Commands==
As noted above, atomic commands will in most cases NOT be issued individually in the schedule, but will be part of higher-level macro-commands.  Commands starting with $ are to be initiated locally on the Schedule Computer.  In the following, <antlist> refers to a list of antenna numbers (1-13, A, B, TEST) in the currently active subarray.  Note that 14, 15, 16 are synonyms for A, B, and TEST.  <antlist> is a space-separated list, with dashes indicating a range, e.g. ant1 ant3 ant5-9.  There will be two instances of the schedule, one for subarray1 and one for subarray2.  All commands issued from the subarray1 schedule by definition only refer to antennas in subarray1, and vice versa.  ‘’’If <antlist> is omitted, the command refers to all antennas in the subarray.’’’  If an antenna number in <antlist> is not in the currently active subarray, it is ignored.  It is expected that <antlist> will nearly always be omitted (i.e. commands will refer to all antennas in a subarray).  If it is desired that a macro-command refer to only some antennas, it is best practice to omit the others from the current subarray first.
A note about subarrays: The SUBARRAY2 command defers to the SUBARRAY1 command, i.e. antennas in <antlist> that are already in subarray1 will not be moved to subarray2 by use of the SUBARRAY2 command.  Examples: (1) Typical commands for solar observing are SUBARRAY1 1-13, SUBARRAY2 A,B.  The TEST input would then be on the “inactive” list and will not receive tracking commands, but its analog backend would be switched according to subarray2.  (2) The typical command for calibrations is SUBARRAY1 1-15 (moves A,B to subarray1). (3) Entering SUBARRAY1 1-13 is sufficient to move A,B back to subarray2 without requiring an explicit SUBARRAY2 command.
===SUBARRAY1 <antlist>===
Specify the list of antenna numbers (1-13, A, B) in subarray 1 (the science subarray).  Antennas not in subarray1 will be placed in subarray2.  Antennas in <antlist> that are currently in subarray2 will be moved to subarray1.

Revision as of 18:11, 27 September 2016

EOVSA Control Language (Draft 2014-Apr-28)

Updates:

  • GN: 2013-Jan-13: Introduced new commands related to the Hittite synthesizers: FSEQ-SCRIPT; LO1A-WRITE; LO1B-WRITE. Added subarray arguments to all FSEQ-* commands.
  • GN: 2013-Jan-16: Added a System Recovery Procedures section to this document

The Schedule program needs to send commands and information to the Array Control Computer (ACC) in order to specify antenna pointing coordinates, tuning, and other system parameters that will change from scan to scan and for different modes of operation (e.g. calibrations of various types, normal solar observing, etc.). This document specifies a command language to accomplish this task, with commands at two levels: (1) High-level commands (macro-commands) that accomplish standard operations in a human-readable form, and will mainly be specified in the top layer of the schedule, and (2) atomic commands from which such macro-commands are constructed, that provide flexibility in defining the order and duration of discrete tasks. Examples of macro-commands would include a SOLPNTCAL command, which initiates a pointing procedure that does multiple offsets of the antennas and takes data that will be analyzed for determining frequency-dependent pointing offsets. Examples of atomic commands would be DATA-ON, which starts data recording, or DOSEQ, which initiates a tuning sequence. The schedule will contain macro-commands associated with files of the same name, e.g. the SOLPNTCAL command would be associated with a file named solpntcal.ctl, which contains a list of atomic commands to execute the SOLPNTCAL. These atomic commands are what will be executed (either locally or by sending the command on to the ACC). It is expected that the ACC will return from receiving an atomic command immediately, and if a command takes some time, the ACC will store and execute the commands in the order received. The currently running atomic command will be indicated in the stateframe, and the Schedule program will examine the stateframe to determine when an individual atomic command is completed. The stateframe will also include the macro command currently being executed. This draft document specifies that both macro- and atomic commands be given as ASCII text in UPPER CASE in the stateframe. It can be typed in lower case in the schedule, but will be converted to upper case prior to display and transfer to the ACC. Although the macro-command will be sent to the ACC, typically this is for information only (for writing into the stateframe), and the ACC will act only on the atomic commands.

List of Atomic Commands

As noted above, atomic commands will in most cases NOT be issued individually in the schedule, but will be part of higher-level macro-commands. Commands starting with $ are to be initiated locally on the Schedule Computer. In the following, <antlist> refers to a list of antenna numbers (1-13, A, B, TEST) in the currently active subarray. Note that 14, 15, 16 are synonyms for A, B, and TEST. <antlist> is a space-separated list, with dashes indicating a range, e.g. ant1 ant3 ant5-9. There will be two instances of the schedule, one for subarray1 and one for subarray2. All commands issued from the subarray1 schedule by definition only refer to antennas in subarray1, and vice versa. ‘’’If <antlist> is omitted, the command refers to all antennas in the subarray.’’’ If an antenna number in <antlist> is not in the currently active subarray, it is ignored. It is expected that <antlist> will nearly always be omitted (i.e. commands will refer to all antennas in a subarray). If it is desired that a macro-command refer to only some antennas, it is best practice to omit the others from the current subarray first. A note about subarrays: The SUBARRAY2 command defers to the SUBARRAY1 command, i.e. antennas in <antlist> that are already in subarray1 will not be moved to subarray2 by use of the SUBARRAY2 command. Examples: (1) Typical commands for solar observing are SUBARRAY1 1-13, SUBARRAY2 A,B. The TEST input would then be on the “inactive” list and will not receive tracking commands, but its analog backend would be switched according to subarray2. (2) The typical command for calibrations is SUBARRAY1 1-15 (moves A,B to subarray1). (3) Entering SUBARRAY1 1-13 is sufficient to move A,B back to subarray2 without requiring an explicit SUBARRAY2 command.

SUBARRAY1 <antlist>

Specify the list of antenna numbers (1-13, A, B) in subarray 1 (the science subarray). Antennas not in subarray1 will be placed in subarray2. Antennas in <antlist> that are currently in subarray2 will be moved to subarray1.