MCEWiki - User contributions [en]

Sync Box

2008-07-10T01:56:27Z

154.20.80.47:

== Sync Box Firmware ==
Fill this in..

== Issue commands to the Sync Box ==
To issue commands to a sync box over an RS-232 line, you can use a Linux program called 'MiniCom'. To install this application, type the following:
> apt-get install...
To start MiniCom:
> sudo minicom
Minicom needs the following options changed for it to work properly:
> <ctrl-a>, <z>, <a>
> <ctrl-a>, <z>, <o>, <Serial port setup> <Serial Device> = /dev/ttyS0
> <ctrl-a>, <z>, <o>, <Serial port setup> <Bps/Par/Bits> = 9600 8N1
> <ctrl-a>, <z>, <o>, <Serial port setup> <Hardware Flow Control> = No
> <ctrl-a>, <z>, <o>, <Serial port setup> <Software Flow Control> = No
> <ctrl-a>, <z>, <o>, <Modem and dialing> <Modem has DCD line> = No
After you modify these settings, remember to save, exit, and restart Minicom.

MCE firmware

2008-07-10T01:55:15Z

154.20.80.47:

Always cleanly reset the MCE after a power-up or a reconfiguration! If you do not, MCE communication with the PC may not work.
> mce_reset_clean

Note that after a reset, not all of the DAC outputs are reset to zero. In addition, values written to RAM-based registers are not reset. To reset these registers, a full reconfiguration is required.
> rs psc cycle_pow 1
> mce_reset_clean

== MCE Firmware Release Information ==
* [[ MCE Firmware Catalog ]]
* [[ MCE Untested features ]]
* [[ MCE bugs ]]

== MCE Features and How-To Guides ==
* [[ Digital 4-pole Butterworth Low-pass filter ]]
* [[ Flux jumping ]]
* [[ Raw-mode readout ]]
* [[ High rate acquisition ]]
* [[ Fast SQ2 Feedback and TES Biasing with an Address Card ]]
* [[ The STOP Command ]]

== Hardware Peripherals ==
* [[ Using Ethernet Blaster ]]
* [[ USB Blaster ]]
* [[ Sync Box ]]
* [[ MCE special configurations | Information on Sync Box and Biasing AC (needs merging) ]]

== Software Tools ==
All that you need to know about logging into our CVS repository can be found here:
* [[ CVS Firmware Repository ]]
* [[ Quartus II Installation ]]
* [[ ModelSim SE Installation ]] (from scratch)

We decided (sadly) NOT to migrate from CVS to SVN, if we ever do here is some information:
* [http://svnbook.red-bean.com/en/1.4/ SVN Manual]
* [[ Firmware Accessing the svn repository | Accessing the SVN Repository ]]
* [[ Firmware svn commit guidelines | SVN Commit Guidelines ]]
* SVN Basic Operations
** [[ Firmware svn tagging | Tagging ]]
** [[ Firmware svn merging | Merging ]]
** [[ Firmware svn branching | Branching ]]
** [[ Firmware svn undelete | Resurrecting Deleted Items ]]

== Firmware Testing ==
* [[ MAS Cheat Sheet ]]

STOP Command

2008-07-10T01:54:30Z

154.20.80.47:

== 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

== 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.

== Test 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:
* 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

== Quick Reference ==
* [[ MAS Cheat Sheet ]]

STOP Command

2008-07-10T01:53:55Z

154.20.80.47:

== 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

== 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.

== Test 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:
* 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

== Quick Reference ==
* [[ MAS Cheat Sheet ]]

STOP Command

2008-07-10T01:53:11Z

154.20.80.47: /* Testing */

== 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.

== Test 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:
* 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

== Quick Reference ==
* [[ MAS Cheat Sheet ]]

STOP Command

2008-07-10T01:52:15Z

154.20.80.47: /* Testing */

== 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

== Quick Reference ==
* [[ MAS Cheat Sheet ]]

MCE firmware

2008-07-10T01:48:39Z

154.20.80.47: /* Hardware Peripherals */

MCE firmware

2008-07-10T01:47:16Z

154.20.80.47:

Always cleanly reset the MCE after a power-up or a reconfiguration! If you do not, MCE communication with the PC may not work.
> mce_reset_clean

Note that after a reset, not all of the DAC outputs are reset to zero. In addition, values written to RAM-based registers are not reset. To reset these registers, a full reconfiguration is required.
> rs psc cycle_pow 1
> mce_reset_clean

== MCE Firmware Release Information ==
* [[ MCE Firmware Catalog ]]
* [[ MCE Untested features ]]
* [[ MCE bugs ]]

== MCE Features and How-To Guides ==
* [[ Digital 4-pole Butterworth Low-pass filter ]]
* [[ Flux jumping ]]
* [[ Raw-mode readout ]]
* [[ High rate acquisition ]]
* [[ Fast SQ2 Feedback and TES Biasing with an Address Card ]]
* [[ The STOP Command ]]

== Hardware Peripherals ==
* [[ Using Ethernet Blaster ]]
* [[ USB Blaster ]]
* [[ Sync Box ]]
* [[ MCE special configurations ]]

== Software Tools ==
All that you need to know about logging into our CVS repository can be found here:
* [[ CVS Firmware Repository ]]
* [[ Quartus II Installation ]]
* [[ ModelSim SE Installation ]] (from scratch)

We decided (sadly) NOT to migrate from CVS to SVN, if we ever do here is some information:
* [http://svnbook.red-bean.com/en/1.4/ SVN Manual]
* [[ Firmware Accessing the svn repository | Accessing the SVN Repository ]]
* [[ Firmware svn commit guidelines | SVN Commit Guidelines ]]
* SVN Basic Operations
** [[ Firmware svn tagging | Tagging ]]
** [[ Firmware svn merging | Merging ]]
** [[ Firmware svn branching | Branching ]]
** [[ Firmware svn undelete | Resurrecting Deleted Items ]]

== Quick Reference Guide for Firmware Testing ==
* [[ MAS Cheat Sheet ]]

Main Page

2008-07-10T01:46:29Z

154.20.80.47:

This wiki is for users and developers of UBC's Multi-Channel Electronics (MCE), and the MCE Acquisition Software (MAS).

== MCE System Components ==

* [[ MCE firmware ]]
* [[ MCE hardware ]]
* [[ Sync Box ]]
* [[ PCI card firmware ]]
* [[ DAS | DAS (pre-MAS)]]
* [[ MAS ]]
* [[ Tuning and IV scripts ]]
* [[ Unix stuff ]]
* [[ Version history ]]

== MediaWiki help and information ==

* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

MAS

2008-07-10T01:46:00Z

154.20.80.47: /* Usage */

== Usage ==

* System applications
** [[mce_cmd]]
** [[mce_status]]
** [[maslog]]
** [[dsp_cmd]]
** [[ MAS Command line how-to ]]

* Special applications
** [[ sq1_servo and sq2_servo ]]
** [[ mce_ramp ]]
** [[ psc_status ]]

* Utilities

* MAS configuration
** [[ MAS start/stop ]]
** [[ mce.cfg ]]
** [[ mas.cfg ]]
** [[ MAS array_id and array_list | array_id and array_list ]]

* MAS file formats
** [[ Runfile format v2 ]]
** [[ MCE flat-file format ]]

* IDL functions
** [[ mas_data.pro ]]
** [[ mas_runfile.pro and mas_runparam.pro ]]
** [[ Other useful IDL routines ]]

* Help
** [[ MCE: Helper programs ]]
** [[ MAS Cheat Sheet ]]

== Development ==

* [[ MAS Bug List ]]
* [[ MAS to-do ]]
* [[ MAS feature requests ]]

== Installation / configuration ==

* [[ MAS PC requirements and initial setup | PC requirements and initial setup]]
* [[ MAS OS setup | OS setup]]
* [[ MAS user setup ]]
* [[ MAS kernel patch compilation | kernel patch compilation]]
* [[ MAS svn repository | SVN repository]]
* [[ Hardware goodlist/badlist ]]

== Trouble-shooting ==

* [[ MAS malfunction diagnosis | diagnosis ]]

Main Page

2008-07-10T01:45:36Z

154.20.80.47:

This wiki is for users and developers of UBC's Multi-Channel Electronics (MCE), and the MCE Acquisition Software (MAS).

== MCE System Components ==

* [[ MCE firmware ]]
* [[ MCE hardware ]]
* [[ Sync Box ]]
* [[ PCI card firmware ]]
* [[ DAS | DAS (pre-MAS)]]
* [[ MAS ]]
* [[ Tuning and IV scripts ]]
* [[ MCE special configurations ]]
* [[ Unix stuff ]]
* [[ Version history ]]

== MediaWiki help and information ==

* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

Sync Box

2008-07-10T01:44:42Z

154.20.80.47:

Sync Box

2008-07-10T01:44:26Z

154.20.80.47:

== Sync Box Firmware ==

== Issue commands to the Sync Box ==
To issue commands to a sync box over an RS-232 line, you can use a Linux program called 'MiniCom'. To install this application, type the following:
> apt-get install...
To start MiniCom:
> sudo minicom
Minicom needs the following options changed for it to work properly:
> <ctrl-a>, <z>, <a>
> <ctrl-a>, <z>, <o>, <Serial port setup> <Serial Device> = /dev/ttyS0
> <ctrl-a>, <z>, <o>, <Serial port setup> <Bps/Par/Bits> = 9600 8N1
> <ctrl-a>, <z>, <o>, <Serial port setup> <Hardware Flow Control> = No
> <ctrl-a>, <z>, <o>, <Serial port setup> <Software Flow Control> = No
> <ctrl-a>, <z>, <o>, <Modem and dialing> <Modem has DCD line> = No
After you modify these settings, remember to save, exit and restart Minicom.

Main Page

2008-07-10T01:43:30Z

154.20.80.47:

This wiki is for users and developers of UBC's Multi-Channel Electronics (MCE), and the MCE Acquisition Software (MAS).

== MCE System Components ==

* [[ MCE firmware ]]
* [[ MCE hardware ]]
* [[ Sync Box ]]
* [[ PCI card firmware ]]
* [[ DAS | DAS (pre-MAS)]]
* [[ MAS ]]
* [[ Tuning and IV scripts ]]
* [[ MCE special configurations ]]
* [[ MCE: Helper programs ]]
* [[ Unix stuff ]]
* [[ Version history ]]

== MediaWiki help and information ==

* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

Main Page

2008-07-10T01:41:36Z

154.20.80.47:

This wiki is for users and developers of UBC's Multi-Channel Electronics (MCE), and the MCE Acquisition Software (MAS).

== MCE System Components ==

* [[ MCE firmware ]]
* [[ MCE hardware ]]
* [[ Sync Box firmware ]]
* [[ PCI card firmware ]]
* [[ DAS | DAS (pre-MAS)]]
* [[ MAS ]]
* [[ Tuning and IV scripts ]]
* [[ MCE special configurations ]]
* [[ MCE: Helper programs ]]
* [[ Unix stuff ]]
* [[ Version history ]]

== MediaWiki help and information ==

* [http://www.mediawiki.org/wiki/Help:Configuration_settings Configuration settings list]
* [http://www.mediawiki.org/wiki/Help:FAQ MediaWiki FAQ]
* [http://mail.wikimedia.org/mailman/listinfo/mediawiki-announce MediaWiki release mailing list]

STOP Command

2008-07-10T01:38:54Z

154.20.80.47:

== 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 ==
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

== Quick Reference ==
* [[ MAS Cheat Sheet ]]

STOP Command

2008-07-10T01:38:18Z

154.20.80.47: /* Testing */

== 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 ==
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

== Quick Reference ==
* [[ MAS Cheat Sheet ]]