Difference between revisions of "STOP Command"
(→Testing) |
|||
Line 14: | Line 14: | ||
== Testing == | == Testing == | ||
+ | '''Challenges''' | ||
+ | |||
Automating the testing of STOP commands is difficult, because MAS currently blocks commands in a shell that has started a data acquisition. This means that an automation script must either open a new shell or run mce_cmd in background mode (with an '&') to STOP an acquisition. In addtion to this, MAS currently does not support commanding the Sync Box, which makes it difficult to test all the different scenarios that could happen. | Automating the testing of STOP commands is difficult, because MAS currently blocks commands in a shell that has started a data acquisition. This means that an automation script must either open a new shell or run mce_cmd in background mode (with an '&') to STOP an acquisition. In addtion to this, MAS currently does not support commanding the Sync Box, which makes it difficult to test all the different scenarios that could happen. | ||
+ | |||
The cmd_translator block on the clock card is the block that nominally runs data acquisitions. It is a complicated piece of code, and requires simulation of at least the following cases: | The cmd_translator block on the clock card is the block that nominally runs data acquisitions. It is a complicated piece of code, and requires simulation of at least the following cases: |
Revision as of 17:52, 9 July 2008
Background
The stop command was invented to allow users to stop data acquisitions in mid-stream. There are a variety of reasons for wanting to do so:
- Malfunction of other subsystems at the telescope
- Not receiving any DV pulses from the Sync Box or other triggering software
Features
STOP command replies:
The STOP command is supported as a special command in the Clock Card firmware. Unlike for WB and RB commands, the MCE replies to the STOP command immediately. Data packets continue to be returned following the reply to the STOP command until all of the remaining ret_dat commands are flushed from the MCE. The last data packet has the 'stop' and 'last_frame' bits set in the status frame header.
STOP commands outside of data runs:
When a STOP command is issued outside of a data run, no data packets are returned. When a STOP command is issued during a data run, the timing of the last data frame does not generally follow the timing that is specified by the '> rb cc data_rate' parameter. In general, the last ret_dat is queued up as quickly as possible, irrespective of the status of '> rb cc use_dv'. For example, when the Clock Card is sourcing its DV pulses from the Sync Box, and a STOP command arrives, it does not wait for the next DV pulse -- instead it issues the last ret_dat immediately. If the Clock Card waited, it might hang if the source of the DV pulses was cut off.
Testing
Challenges
Automating the testing of STOP commands is difficult, because MAS currently blocks commands in a shell that has started a data acquisition. This means that an automation script must either open a new shell or run mce_cmd in background mode (with an '&') to STOP an acquisition. In addtion to this, MAS currently does not support commanding the Sync Box, which makes it difficult to test all the different scenarios that could happen.
The cmd_translator block on the clock card is the block that nominally runs data acquisitions. It is a complicated piece of code, and requires simulation of at least the following cases:
- Acquisition of one frame of data
- Acquisition of multiple frames of data
- Acquisition while sourcing the DV from the Sync Box (use_sync=2, use_dv=2, select_clk=1)
- Acquisition while sourcing the DV from the Sync Box's input (use_sync=2, use_dv=2, select_clk=1)
- Acquisition while sourcing the DV from the Sync Box and disconnecting the Sync Box fibre.
- Acquisition while sourcing the DV from the Sync Box with the fibre initially disconnected
- Acquisition while turing the Sync Box output off and then on.
All the cases above should be repeated in the following scenarios:
- a STOP command should be issued before the first frame is returned
- a STOP command should be issued during the acquisition
- a STOP command should be issued after the acquisition
How to Issue STOP Command
From a shell:
> mce_cmd -x stop <card_addr> ret_dat
In MAS' interactive mode:
> stop <card_addr> ret_dat
In order to stop the MAS data process only from a shell:
> mce_cmd -x fakestop