MCEWiki - User contributions [en]

https://e-mode.phas.ubc.ca/mcewiki/api.php?action=feedcontributions&feedformat=atom&user=Sysop MCEWiki - User contributions [en] 2026-05-09T22:57:03Z User contributions MediaWiki 1.31.16 https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MCE_config_template_system&diff=1614 MCE config template system 2008-03-06T11:01:59Z

<p>Sysop: </p> <hr /> <div>An important component of the current MCE configuration system is the "mce_config_template" file. This file is a bash script that puts the MCE in some desired state, which usually means that it sets up the biases and locking points of the squids and series arrays to the values determined in the most recent auto-tuning.<br /> <br /> = General structure =<br /> <br /> In previous versions of MCE software, there was a template file called config_mce_auto_setup_<date>, with date of the form YYYYMMDD, that lived in the /data/cryo/<date> folder (which was linked to /data/cryo/current_data and was the destination for all MCE data files). When the [[ Auto-tuning IDL code | auto-tune ]] was run, certain lines of the config script were updated to reflect the biases and locking points discovered by the auto-tune code. The auto-tune code would then run the updated config script to load the values into the MCE in preparation for the next stage.<br /> <br /> In order to create a more flexible and robust system, the auto-tune programs no longer edit the config script directly. Instead, there is configuration file, called "experiment.cfg", where the auto-tune programs can read and write values. A config script is then generated by running "mce_make_config", which creates a config script based on the values in experiment.cfg.<br /> <br /> The auto-tune read and write is accomplished via IDL functions called "load_exp_params" and "save_exp_params". These functions are in "load_exp_params.pro", which is automatically generated by the program [[ mas_param ]] based on a template for experiment.cfg. They allow IDL to import settings from experiment.cfg as an IDL structure, manipulate them using normal IDL vector operations, and then save the structure data back to the file.<br /> <br /> The mce_make_config script constructs a config script by combining various pre-defined blocks of bash code with a block of bash variable declarations that is generated by [[ mas_param ]] from experiment.cfg.<br /> <br /> = experiment.cfg =<br /> <br /> The experiment.cfg file structure is that of libconfig (http://www.hyperrealm.com/libconfig/). Here are some typical lines:<br /> <br /> # output level and time interval for driving detectors normal.<br /> <br /> tes_bias_idle = [0, 0, 0];<br /> tes_bias_normal = [65000, 65000, 65000];<br /> tes_bias_normal_time = 0.1;<br /> <br /> # Note that each entry of flux_quanta_rc# is repeated 41 times and<br /> # written to 'rc# flux_quanta%'<br /> <br /> flux_quanta = [ 0, 0, 0, 0, 0, 0, 0, 0,<br /> 0, 0, 0, 0, 0, 0, 0, 0,<br /> 0, 0, 0, 0, 0, 0, 0, 0,<br /> 0, 0, 0, 0, 0, 0, 0, 0 ];<br /> <br /> Although libconfig permits complex nested data structures, experiment.cfg is restricted to root-level simple data types (strings, floats, integers, arrays of floats, and arrays of integers).<br /> <br /> Unfortunately, experiment.cfg contains values associate with<br /> * very stable properties that define the hardware configuration (e.g. number of rows of squids and sync box presence/absence)<br /> * properties that must be manipulated during auto-tuning but then should return to some experiment default (e.g. rc data_mode)<br /> * settings that a user can manipulate to select different auto-tuning options (e.g. the list of rows for which to generate sq1 bias ramp plots)<br /> * properties that are discovered or revised at various stages of the auto-tuning (e.g. the sq2 feedback lock points)<br /> <br /> This means that it is necessary to keep a few copies of experiment.cfg lying around to avoid corruption of certain properties. In particular, at any time there will be:<br /> * a pristine copy of experiment.cfg in $MAS_TEMPLATE; this will define preferred values for data mode, the hardware configuration, and the auto-tuning technique. This will occasionally be updated, by hand, to select different tuning preferences.<br /> * a working template copy, called experiment_template.cfg, in $MAS_DATA (/data/cryo/current_data), which becomes the starting point for auto-tuning.<br /> * a target copy, in $MAS_DATA, which is actively edited by the auto-tuning programs as the auto-tune progresses.<br /> <br /> = Ok, I'll level with you =<br /> <br /> This is broken, because partial tunings (short=2) will trash experiment.cfg with experiment_template.cfg. I think it can be fixed; we just have to separate "final settings" from "set this to this now" settings.</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MCE_script&diff=1613 MCE script 2008-03-06T10:21:24Z

<p>Sysop: </p> <hr /> <div>* Auto-tuning system<br /> ** [[ Auto-tuning IDL code ]]<br /> ** [[ mce_config_template system ]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MCE_script&diff=1612 MCE script 2008-03-06T10:21:07Z

<p>Sysop: </p> <hr /> <div>* Auto-tuning system<br /> ** Auto-tuning IDL code<br /> ** mce_config_template system</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Sq1_servo_and_sq2_servo&diff=1611 Sq1 servo and sq2 servo 2008-03-06T10:20:16Z

<p>Sysop: </p> <hr /> <div>== Bug list ==<br /> <br /> * sq1servo and sq2servo may calculate out-of-range feedback values</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS&diff=1610 MAS 2008-03-06T10:19:50Z

<p>Sysop: /* Usage */</p> <hr /> <div>== Usage ==<br /> <br /> * System applications<br /> ** [[mce_cmd]]<br /> ** [[mce_status]]<br /> ** [[maslog]]<br /> ** [[dsp_cmd]]<br /> ** [[ MAS Command line how-to ]]<br /> <br /> * Special applications<br /> ** [[ sq1_servo and sq2_servo ]]<br /> ** [[ mce_ramp ]]<br /> ** [[ psc_status ]]<br /> <br /> * Utilities<br /> <br /> * MAS configuration<br /> ** [[ MAS start/stop ]]<br /> ** [[ mce.cfg ]]<br /> ** [[ mas.cfg ]]<br /> <br /> * MAS file formats<br /> ** [[ Runfile format v2 ]]<br /> <br /> == Development ==<br /> <br /> * [[ MAS Bug List ]]<br /> * [[ MAS to-do ]]<br /> * [[ MAS feature requests ]]<br /> <br /> == Installation / configuration ==<br /> <br /> * [[ MAS PC requirements and initial setup | PC requirements and initial setup]]<br /> * [[ MAS OS setup | OS setup]]<br /> * [[ MAS kernel patch compilation | kernel patch compilation]]<br /> * [[ MAS svn repository | SVN repository]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS&diff=1609 MAS 2008-03-06T10:19:33Z

<p>Sysop: /* Usage */</p> <hr /> <div>== Usage ==<br /> <br /> * System applications<br /> ** [[mce_cmd]]<br /> ** [[mce_status]]<br /> ** [[maslog]]<br /> ** [[dsp_cmd]]<br /> ** [[ MAS Command line how-to ]]<br /> <br /> * Special applications<br /> ** sq1_servo and sq2_servo<br /> ** mce_ramp<br /> ** psc_status<br /> <br /> * Utilities<br /> <br /> * MAS configuration<br /> ** [[ MAS start/stop ]]<br /> ** [[ mce.cfg ]]<br /> ** [[ mas.cfg ]]<br /> <br /> * MAS file formats<br /> ** [[ Runfile format v2 ]]<br /> <br /> == Development ==<br /> <br /> * [[ MAS Bug List ]]<br /> * [[ MAS to-do ]]<br /> * [[ MAS feature requests ]]<br /> <br /> == Installation / configuration ==<br /> <br /> * [[ MAS PC requirements and initial setup | PC requirements and initial setup]]<br /> * [[ MAS OS setup | OS setup]]<br /> * [[ MAS kernel patch compilation | kernel patch compilation]]<br /> * [[ MAS svn repository | SVN repository]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Mce_cmd&diff=1608 Mce cmd 2008-03-06T10:17:48Z

<p>Sysop: </p> <hr /> <div>[[ MAS | Return to MAS ]]<br /> <br /> = Introduction =<br /> <br /> mce_cmd provides an interface between a Linux shell and the MCE. The application can run interactively (accepting commands from a user and issuing responses to stdout), or can be used to execute scripts containing mce_cmd instructions.<br /> <br /> = Running mce_cmd =<br /> <br /> == Interactive mode ==<br /> <br /> When invoked with the '-i' option, mce_cmd can be used interactively. A session command history (similar to the one in bash) can be accessed with the up and down arrow keys, and line editing is possible using emacs-based key-mappings.<br /> mce_cmd -i<br /> <br /> After displaying a version message, mce_cmd will be ready to accept input. There is no user prompt.<br /> <br /> == Single command execution ==<br /> <br /> A single command can be issued using the '-x' option:<br /> mce_cmd -x rb cc fw_rev<br /> The application will execute the command, display any output, and exit. Currently, only single commands can be executed from the command line.<br /> <br /> == Script execution ==<br /> <br /> The '-f' option tell mce_cmd to read lines from the specified file and attempt to execute them. The '-q' option suppresses unnecessary output.<br /> mce_cmd -q -f my_script.scr<br /> <br /> When redirecting commands to mce_cmd, the '-r' option should be used to disable the command history/line editing features of mce_cmd and decrease the execution time.<br /> cat my_script.scr | mce_cmd -q -r<br /> <br /> If a script command fails, mce_cmd will exit. To suppress that behaviour (and continue attempting commands even after one of them has failed), pass the '-i' option.<br /> <br /> <br /> = Commands =<br /> <br /> We can break the mce_cmd command set into three broad categories: MCE commands, data acquisition commands, and output formatting commands.<br /> <br /> == Special hardware commands ==<br /> <br /> === MCE_RESET: reset the MCE using special character override ===<br /> <br /> The mce_reset command causes the PCI card to transmit a special character over the fibre-optic connection to the MCE. This causes the MCE to reinitialize. It is advisable to wait several microseconds following the mce_reset command before issuing other MCE commands.<br /> <br /> Syntax:<br /> mce_reset<br /> <br /> === DSP_RESET: reset the PCI card DSP firmware ===<br /> <br /> The dsp_reset command causes the PCI card to reset.<br /> <br /> Syntax:<br /> dsp_reset<br /> <br /> <br /> <br /> == MCE data block commands ==<br /> <br /> MCE configuration data is stored in blocks at certain card and parameter addresses (which we will call "block locations"). A typical block address is<br /> rc2 flx_quanta4<br /> This block consists of 41 32-bit words where the user writes the squid-1 flux quantum size for column 4 on readout card 2.<br /> <br /> The most basic data manipulation commands are RB ("read block") and WB<br /> ("write block"). These commands read from or write to the entire range of<br /> data at the block location, starting at the beginning of the block.<br /> <br /> The commands RRA ("read range") and WRA ("write range") can be used to<br /> read or write particular subranges of the data in a block location.<br /> <br /> All read and write commands take a card (or [[ Virtual cards | virtual card ]]) name and a<br /> parameter name as the first two arguments. <br /> <br /> === RB: read block ===<br /> <br /> The read block command returns the entire contents of a block location.<br /> <br /> Syntax:<br /> rb <card> <param><br /> Example:<br /> rb rc1 adc_offset0<br /> Line 1 : ok : 10 11 9 8 12 13 14 15<br /> <br /> <br /> === WB: write block ===<br /> <br /> The write block command writes the given data to the specified block location. If the number of data is smaller than block size, the remaining block elements will not be altered. If the number of data is larger than the block size, the behaviour depends on the implementation of the block location.<br /> <br /> Syntax:<br /> wb <card> <param> [val0 val1 val2 ...]<br /> Example:<br /> wb rc1 adc_offset0 0 1 2<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 12 13 14 15<br /> <br /> === RRA: read range ===<br /> <br /> The read range command returns <count> values from the block location, starting from the value at <start_index> (indexed from 0).<br /> <br /> Syntax:<br /> rra <card> <param> <start_index> <count><br /> Example:<br /> rra rc1 adc_offset0 2 4<br /> Line 1 : ok : 2 8 12 13<br /> <br /> === WRA: write range ===<br /> <br /> The write range command writes the given values into the block location, starting at <start_index> (indexed from 0). Other block data (i.e. at indices lower than start_index) are not changed. (This command is implemented as a read-update-write and will usually take twice as long to execute as a WB command.)<br /> <br /> Syntax:<br /> wra <card> <param> <start_index> [val0 val1 val2 ...]<br /> Example:<br /> wra rc1 adc_offset0 4 100 200<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 100 200 14 15<br /> <br /> == MCE data acquisition commands ==<br /> <br /> The acquisition of frame data is achieved by first configuring an output system (by specifying an output format, filename, and the target readout cards), and then by issuing ACQ_GO commands to acquire frames.<br /> <br /> This simplest example will acquire 1000 frames from rc2 into the file /data/cryo/current_data/test:<br /> acq_config /data/cryo/current_data/test rc2<br /> Line 1 : ok<br /> acq_go 1000<br /> Line 2 : ok<br /> <br /> The configuration commands have mnemonics that begin with "ACQ_CONFIG". They allow a small variety of output formats.<br /> <br /> === acq_config : configure simple MCE frame file ===<br /> <br /> The acq_config command configures a single output file to receive MCE frames.<br /> <br /> Syntax:<br /> acq_config <filename> <readout_card><br /> <br /> Example:<br /> acq_config test1.dat rc2<br /> <br /> === acq_config_fs : configure file-sequenced MCE frame file ===<br /> <br /> The acq_config_fs command will result in the outputting of the frame data into a set of files whose filename contains an increasing index. The output file is changed after <change_interval> frames. The output files will be called <filename>.000, <filename>.001, etc.<br /> <br /> Syntax:<br /> acq_config_fs <filename> <readout_card> <change_interval><br /> <br /> <br /> === acq_path : set the default path for data output ===<br /> <br /> The acq_path command sets the default output directory for frame data. This path is only appled if the filenames given in acq_config_* do not specify a relative path. The given path can be absolute, or relative to the mce_cmd's run-time working directory. The default output location can also be specified using the '-o' command line option.<br /> <br /> Syntax:<br /> acq_path <path><br /> <br /> Example:<br /> acq_path /data/cryo/current_data<br /> acq_config test1 rc1<br /> acq_go 10<br /> <br /> === acq_go : acquire frame data ===<br /> <br /> The acq_go command causes the MCE to begin acquiring data. The frame data will be stored according to the most recent acq_config* command. It is not usually necessary to reconfigure the output system (i.e. perform another acq_config) between acq_go commands. The exception to this is that if the frame structure changes (i.e. "cc num_rows_reported" is altered), then acq_config should be issued again so that the acquisition system can determine the frame size. <br /> <br /> Syntax:<br /> acq_go <frame_count><br /> <br /> Example:<br /> acq_config tes_bias_ramp rc1<br /> wb tes bias 5 5 5<br /> acq_go 1<br /> wb tes bias 10 10 10<br /> acq_go 1<br /> <br /> = Output formatting =<br /> <br /> Normally, mce_cmd produces a line of output following each command. The output consists of two or three parts, separated by colons. If in line prefix mode (which is the default) the output is:<br /> Line <line number>: <success> [: data ... ]<br /> <br /> The <success> indicator will be "ok" if the command succeeded, or "error" otherwise. Successful commands may return data (for example, an RB command). Failed commands will always return an error message as the data.<br /> <br /> If mce_cmd is invoked with prefixes turned off ('-p'), the output format is<br /> <success> [: data]<br /> <br /> If mce_cmd is invoked in quiet mode ('q'), then all command responses that have no output data are suppressed. In quiet mode, "Line 12: ok" will not be displayed.<br /> <br /> <br /> ----<br /> [[ MAS | Return to MAS ]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Mce_cmd&diff=1607 Mce cmd 2008-03-06T10:07:32Z

<p>Sysop: /* Output formatting */</p> <hr /> <div>= Introduction =<br /> <br /> mce_cmd provides an interface between a Linux shell and the MCE. The application can run interactively (accepting commands from a user and issuing responses to stdout), or can be used to execute scripts containing mce_cmd instructions.<br /> <br /> = Running mce_cmd =<br /> <br /> == Interactive mode ==<br /> <br /> When invoked with the '-i' option, mce_cmd can be used interactively. A session command history (similar to the one in bash) can be accessed with the up and down arrow keys, and line editing is possible using emacs-based key-mappings.<br /> mce_cmd -i<br /> <br /> After displaying a version message, mce_cmd will be ready to accept input. There is no user prompt.<br /> <br /> == Single command execution ==<br /> <br /> A single command can be issued using the '-x' option:<br /> mce_cmd -x rb cc fw_rev<br /> The application will execute the command, display any output, and exit. Currently, only single commands can be executed from the command line.<br /> <br /> == Script execution ==<br /> <br /> The '-f' option tell mce_cmd to read lines from the specified file and attempt to execute them. The '-q' option suppresses unnecessary output.<br /> mce_cmd -q -f my_script.scr<br /> <br /> When redirecting commands to mce_cmd, the '-r' option should be used to disable the command history/line editing features of mce_cmd and decrease the execution time.<br /> cat my_script.scr | mce_cmd -q -r<br /> <br /> If a script command fails, mce_cmd will exit. To suppress that behaviour (and continue attempting commands even after one of them has failed), pass the '-i' option.<br /> <br /> <br /> = Commands =<br /> <br /> We can break the mce_cmd command set into three broad categories: MCE commands, data acquisition commands, and output formatting commands.<br /> <br /> == Special hardware commands ==<br /> <br /> === MCE_RESET: reset the MCE using special character override ===<br /> <br /> The mce_reset command causes the PCI card to transmit a special character over the fibre-optic connection to the MCE. This causes the MCE to reinitialize. It is advisable to wait several microseconds following the mce_reset command before issuing other MCE commands.<br /> <br /> Syntax:<br /> mce_reset<br /> <br /> === DSP_RESET: reset the PCI card DSP firmware ===<br /> <br /> The dsp_reset command causes the PCI card to reset.<br /> <br /> Syntax:<br /> dsp_reset<br /> <br /> <br /> <br /> == MCE data block commands ==<br /> <br /> MCE configuration data is stored in blocks at certain card and parameter addresses (which we will call "block locations"). A typical block address is<br /> rc2 flx_quanta4<br /> This block consists of 41 32-bit words where the user writes the squid-1 flux quantum size for column 4 on readout card 2.<br /> <br /> The most basic data manipulation commands are RB ("read block") and WB<br /> ("write block"). These commands read from or write to the entire range of<br /> data at the block location, starting at the beginning of the block.<br /> <br /> The commands RRA ("read range") and WRA ("write range") can be used to<br /> read or write particular subranges of the data in a block location.<br /> <br /> All read and write commands take a card (or [[ Virtual cards | virtual card ]]) name and a<br /> parameter name as the first two arguments. <br /> <br /> === RB: read block ===<br /> <br /> The read block command returns the entire contents of a block location.<br /> <br /> Syntax:<br /> rb <card> <param><br /> Example:<br /> rb rc1 adc_offset0<br /> Line 1 : ok : 10 11 9 8 12 13 14 15<br /> <br /> <br /> === WB: write block ===<br /> <br /> The write block command writes the given data to the specified block location. If the number of data is smaller than block size, the remaining block elements will not be altered. If the number of data is larger than the block size, the behaviour depends on the implementation of the block location.<br /> <br /> Syntax:<br /> wb <card> <param> [val0 val1 val2 ...]<br /> Example:<br /> wb rc1 adc_offset0 0 1 2<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 12 13 14 15<br /> <br /> === RRA: read range ===<br /> <br /> The read range command returns <count> values from the block location, starting from the value at <start_index> (indexed from 0).<br /> <br /> Syntax:<br /> rra <card> <param> <start_index> <count><br /> Example:<br /> rra rc1 adc_offset0 2 4<br /> Line 1 : ok : 2 8 12 13<br /> <br /> === WRA: write range ===<br /> <br /> The write range command writes the given values into the block location, starting at <start_index> (indexed from 0). Other block data (i.e. at indices lower than start_index) are not changed. (This command is implemented as a read-update-write and will usually take twice as long to execute as a WB command.)<br /> <br /> Syntax:<br /> wra <card> <param> <start_index> [val0 val1 val2 ...]<br /> Example:<br /> wra rc1 adc_offset0 4 100 200<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 100 200 14 15<br /> <br /> == MCE data acquisition commands ==<br /> <br /> The acquisition of frame data is achieved by first configuring an output system (by specifying an output format, filename, and the target readout cards), and then by issuing ACQ_GO commands to acquire frames.<br /> <br /> This simplest example will acquire 1000 frames from rc2 into the file /data/cryo/current_data/test:<br /> acq_config /data/cryo/current_data/test rc2<br /> Line 1 : ok<br /> acq_go 1000<br /> Line 2 : ok<br /> <br /> The configuration commands have mnemonics that begin with "ACQ_CONFIG". They allow a small variety of output formats.<br /> <br /> === acq_config : configure simple MCE frame file ===<br /> <br /> The acq_config command configures a single output file to receive MCE frames.<br /> <br /> Syntax:<br /> acq_config <filename> <readout_card><br /> <br /> Example:<br /> acq_config test1.dat rc2<br /> <br /> === acq_config_fs : configure file-sequenced MCE frame file ===<br /> <br /> The acq_config_fs command will result in the outputting of the frame data into a set of files whose filename contains an increasing index. The output file is changed after <change_interval> frames. The output files will be called <filename>.000, <filename>.001, etc.<br /> <br /> Syntax:<br /> acq_config_fs <filename> <readout_card> <change_interval><br /> <br /> <br /> === acq_path : set the default path for data output ===<br /> <br /> The acq_path command sets the default output directory for frame data. This path is only appled if the filenames given in acq_config_* do not specify a relative path. The given path can be absolute, or relative to the mce_cmd's run-time working directory. The default output location can also be specified using the '-o' command line option.<br /> <br /> Syntax:<br /> acq_path <path><br /> <br /> Example:<br /> acq_path /data/cryo/current_data<br /> acq_config test1 rc1<br /> acq_go 10<br /> <br /> === acq_go : acquire frame data ===<br /> <br /> The acq_go command causes the MCE to begin acquiring data. The frame data will be stored according to the most recent acq_config* command. It is not usually necessary to reconfigure the output system (i.e. perform another acq_config) between acq_go commands. The exception to this is that if the frame structure changes (i.e. "cc num_rows_reported" is altered), then acq_config should be issued again so that the acquisition system can determine the frame size. <br /> <br /> Syntax:<br /> acq_go <frame_count><br /> <br /> Example:<br /> acq_config tes_bias_ramp rc1<br /> wb tes bias 5 5 5<br /> acq_go 1<br /> wb tes bias 10 10 10<br /> acq_go 1<br /> <br /> = Output formatting =<br /> <br /> Normally, mce_cmd produces a line of output following each command. The output consists of two or three parts, separated by colons. If in line prefix mode (which is the default) the output is:<br /> Line <line number>: <success> [: data ... ]<br /> <br /> The <success> indicator will be "ok" if the command succeeded, or "error" otherwise. Successful commands may return data (for example, an RB command). Failed commands will always return an error message as the data.<br /> <br /> If mce_cmd is invoked with prefixes turned off ('-p'), the output format is<br /> <success> [: data]<br /> <br /> If mce_cmd is invoked in quiet mode ('q'), then all command responses that have no output data are suppressed. In quiet mode, "Line 12: ok" will not be displayed.</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Mce_cmd&diff=1606 Mce cmd 2008-03-06T09:16:49Z

<p>Sysop: /* Commands */</p> <hr /> <div>= Introduction =<br /> <br /> mce_cmd provides an interface between a Linux shell and the MCE. The application can run interactively (accepting commands from a user and issuing responses to stdout), or can be used to execute scripts containing mce_cmd instructions.<br /> <br /> = Running mce_cmd =<br /> <br /> == Interactive mode ==<br /> <br /> When invoked with the '-i' option, mce_cmd can be used interactively. A session command history (similar to the one in bash) can be accessed with the up and down arrow keys, and line editing is possible using emacs-based key-mappings.<br /> mce_cmd -i<br /> <br /> After displaying a version message, mce_cmd will be ready to accept input. There is no user prompt.<br /> <br /> == Single command execution ==<br /> <br /> A single command can be issued using the '-x' option:<br /> mce_cmd -x rb cc fw_rev<br /> The application will execute the command, display any output, and exit. Currently, only single commands can be executed from the command line.<br /> <br /> == Script execution ==<br /> <br /> The '-f' option tell mce_cmd to read lines from the specified file and attempt to execute them. The '-q' option suppresses unnecessary output.<br /> mce_cmd -q -f my_script.scr<br /> <br /> When redirecting commands to mce_cmd, the '-r' option should be used to disable the command history/line editing features of mce_cmd and decrease the execution time.<br /> cat my_script.scr | mce_cmd -q -r<br /> <br /> If a script command fails, mce_cmd will exit. To suppress that behaviour (and continue attempting commands even after one of them has failed), pass the '-i' option.<br /> <br /> <br /> = Commands =<br /> <br /> We can break the mce_cmd command set into three broad categories: MCE commands, data acquisition commands, and output formatting commands.<br /> <br /> == Special hardware commands ==<br /> <br /> === MCE_RESET: reset the MCE using special character override ===<br /> <br /> The mce_reset command causes the PCI card to transmit a special character over the fibre-optic connection to the MCE. This causes the MCE to reinitialize. It is advisable to wait several microseconds following the mce_reset command before issuing other MCE commands.<br /> <br /> Syntax:<br /> mce_reset<br /> <br /> === DSP_RESET: reset the PCI card DSP firmware ===<br /> <br /> The dsp_reset command causes the PCI card to reset.<br /> <br /> Syntax:<br /> dsp_reset<br /> <br /> <br /> <br /> == MCE data block commands ==<br /> <br /> MCE configuration data is stored in blocks at certain card and parameter addresses (which we will call "block locations"). A typical block address is<br /> rc2 flx_quanta4<br /> This block consists of 41 32-bit words where the user writes the squid-1 flux quantum size for column 4 on readout card 2.<br /> <br /> The most basic data manipulation commands are RB ("read block") and WB<br /> ("write block"). These commands read from or write to the entire range of<br /> data at the block location, starting at the beginning of the block.<br /> <br /> The commands RRA ("read range") and WRA ("write range") can be used to<br /> read or write particular subranges of the data in a block location.<br /> <br /> All read and write commands take a card (or [[ Virtual cards | virtual card ]]) name and a<br /> parameter name as the first two arguments. <br /> <br /> === RB: read block ===<br /> <br /> The read block command returns the entire contents of a block location.<br /> <br /> Syntax:<br /> rb <card> <param><br /> Example:<br /> rb rc1 adc_offset0<br /> Line 1 : ok : 10 11 9 8 12 13 14 15<br /> <br /> <br /> === WB: write block ===<br /> <br /> The write block command writes the given data to the specified block location. If the number of data is smaller than block size, the remaining block elements will not be altered. If the number of data is larger than the block size, the behaviour depends on the implementation of the block location.<br /> <br /> Syntax:<br /> wb <card> <param> [val0 val1 val2 ...]<br /> Example:<br /> wb rc1 adc_offset0 0 1 2<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 12 13 14 15<br /> <br /> === RRA: read range ===<br /> <br /> The read range command returns <count> values from the block location, starting from the value at <start_index> (indexed from 0).<br /> <br /> Syntax:<br /> rra <card> <param> <start_index> <count><br /> Example:<br /> rra rc1 adc_offset0 2 4<br /> Line 1 : ok : 2 8 12 13<br /> <br /> === WRA: write range ===<br /> <br /> The write range command writes the given values into the block location, starting at <start_index> (indexed from 0). Other block data (i.e. at indices lower than start_index) are not changed. (This command is implemented as a read-update-write and will usually take twice as long to execute as a WB command.)<br /> <br /> Syntax:<br /> wra <card> <param> <start_index> [val0 val1 val2 ...]<br /> Example:<br /> wra rc1 adc_offset0 4 100 200<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 100 200 14 15<br /> <br /> == MCE data acquisition commands ==<br /> <br /> The acquisition of frame data is achieved by first configuring an output system (by specifying an output format, filename, and the target readout cards), and then by issuing ACQ_GO commands to acquire frames.<br /> <br /> This simplest example will acquire 1000 frames from rc2 into the file /data/cryo/current_data/test:<br /> acq_config /data/cryo/current_data/test rc2<br /> Line 1 : ok<br /> acq_go 1000<br /> Line 2 : ok<br /> <br /> The configuration commands have mnemonics that begin with "ACQ_CONFIG". They allow a small variety of output formats.<br /> <br /> === acq_config : configure simple MCE frame file ===<br /> <br /> The acq_config command configures a single output file to receive MCE frames.<br /> <br /> Syntax:<br /> acq_config <filename> <readout_card><br /> <br /> Example:<br /> acq_config test1.dat rc2<br /> <br /> === acq_config_fs : configure file-sequenced MCE frame file ===<br /> <br /> The acq_config_fs command will result in the outputting of the frame data into a set of files whose filename contains an increasing index. The output file is changed after <change_interval> frames. The output files will be called <filename>.000, <filename>.001, etc.<br /> <br /> Syntax:<br /> acq_config_fs <filename> <readout_card> <change_interval><br /> <br /> <br /> === acq_path : set the default path for data output ===<br /> <br /> The acq_path command sets the default output directory for frame data. This path is only appled if the filenames given in acq_config_* do not specify a relative path. The given path can be absolute, or relative to the mce_cmd's run-time working directory. The default output location can also be specified using the '-o' command line option.<br /> <br /> Syntax:<br /> acq_path <path><br /> <br /> Example:<br /> acq_path /data/cryo/current_data<br /> acq_config test1 rc1<br /> acq_go 10<br /> <br /> === acq_go : acquire frame data ===<br /> <br /> The acq_go command causes the MCE to begin acquiring data. The frame data will be stored according to the most recent acq_config* command. It is not usually necessary to reconfigure the output system (i.e. perform another acq_config) between acq_go commands. The exception to this is that if the frame structure changes (i.e. "cc num_rows_reported" is altered), then acq_config should be issued again so that the acquisition system can determine the frame size. <br /> <br /> Syntax:<br /> acq_go <frame_count><br /> <br /> Example:<br /> acq_config tes_bias_ramp rc1<br /> wb tes bias 5 5 5<br /> acq_go 1<br /> wb tes bias 10 10 10<br /> acq_go 1<br /> <br /> = Output formatting =<br /> <br /> The output consists of two or three parts, separated by colons. If in line prefix mode (which is the default) the output is:<br /> Line <line number>: <success> [: data ... ]<br /> <br /> The <success> indicator will be "ok" if the command succeeded, or "error" otherwise. Successful commands may return data (for example, an RB command). Failed commands will always return an error message as the data.<br /> <br /> If mce_cmd is invoked with prefixes turned off ('-p'), the output format is<br /> <success> [: data]<br /> <br /> If mce_cmd is invoked in quiet mode ('q'), then all command responses that have no output data are suppressed. In quiet mode, "Line 12: ok" will not be displayed.</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Mce_cmd&diff=1605 Mce cmd 2008-03-06T09:12:39Z

<p>Sysop: /* Output formatting */</p> <hr /> <div>= Introduction =<br /> <br /> mce_cmd provides an interface between a Linux shell and the MCE. The application can run interactively (accepting commands from a user and issuing responses to stdout), or can be used to execute scripts containing mce_cmd instructions.<br /> <br /> = Running mce_cmd =<br /> <br /> == Interactive mode ==<br /> <br /> When invoked with the '-i' option, mce_cmd can be used interactively. A session command history (similar to the one in bash) can be accessed with the up and down arrow keys, and line editing is possible using emacs-based key-mappings.<br /> mce_cmd -i<br /> <br /> After displaying a version message, mce_cmd will be ready to accept input. There is no user prompt.<br /> <br /> == Single command execution ==<br /> <br /> A single command can be issued using the '-x' option:<br /> mce_cmd -x rb cc fw_rev<br /> The application will execute the command, display any output, and exit. Currently, only single commands can be executed from the command line.<br /> <br /> == Script execution ==<br /> <br /> The '-f' option tell mce_cmd to read lines from the specified file and attempt to execute them. The '-q' option suppresses unnecessary output.<br /> mce_cmd -q -f my_script.scr<br /> <br /> When redirecting commands to mce_cmd, the '-r' option should be used to disable the command history/line editing features of mce_cmd and decrease the execution time.<br /> cat my_script.scr | mce_cmd -q -r<br /> <br /> If a script command fails, mce_cmd will exit. To suppress that behaviour (and continue attempting commands even after one of them has failed), pass the '-i' option.<br /> <br /> <br /> = Commands =<br /> <br /> We can break the mce_cmd command set into three broad categories: MCE commands, data acquisition commands, and output formatting commands.<br /> <br /> == MCE data block commands ==<br /> <br /> MCE configuration data is stored in blocks at certain card and parameter addresses (which we will call "block locations"). A typical block address is<br /> rc2 flx_quanta4<br /> This block consists of 41 32-bit words where the user writes the squid-1 flux quantum size for column 4 on readout card 2.<br /> <br /> The most basic data manipulation commands are RB ("read block") and WB<br /> ("write block"). These commands read from or write to the entire range of<br /> data at the block location, starting at the beginning of the block.<br /> <br /> The commands RRA ("read range") and WRA ("write range") can be used to<br /> read or write particular subranges of the data in a block location.<br /> <br /> All read and write commands take a card (or [[ Virtual cards | virtual card ]]) name and a<br /> parameter name as the first two arguments. <br /> <br /> === RB: read block ===<br /> <br /> The read block command returns the entire contents of a block location.<br /> <br /> Syntax:<br /> rb <card> <param><br /> Example:<br /> rb rc1 adc_offset0<br /> Line 1 : ok : 10 11 9 8 12 13 14 15<br /> <br /> <br /> === WB: write block ===<br /> <br /> The write block command writes the given data to the specified block location. If the number of data is smaller than block size, the remaining block elements will not be altered. If the number of data is larger than the block size, the behaviour depends on the implementation of the block location.<br /> <br /> Syntax:<br /> wb <card> <param> [val0 val1 val2 ...]<br /> Example:<br /> wb rc1 adc_offset0 0 1 2<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 12 13 14 15<br /> <br /> === RRA: read range ===<br /> <br /> The read range command returns <count> values from the block location, starting from the value at <start_index> (indexed from 0).<br /> <br /> Syntax:<br /> rra <card> <param> <start_index> <count><br /> Example:<br /> rra rc1 adc_offset0 2 4<br /> Line 1 : ok : 2 8 12 13<br /> <br /> === WRA: write range ===<br /> <br /> The write range command writes the given values into the block location, starting at <start_index> (indexed from 0). Other block data (i.e. at indices lower than start_index) are not changed. (This command is implemented as a read-update-write and will usually take twice as long to execute as a WB command.)<br /> <br /> Syntax:<br /> wra <card> <param> <start_index> [val0 val1 val2 ...]<br /> Example:<br /> wra rc1 adc_offset0 4 100 200<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 100 200 14 15<br /> <br /> == MCE data acquisition commands ==<br /> <br /> The acquisition of frame data is achieved by first configuring an output system (by specifying an output format, filename, and the target readout cards), and then by issuing ACQ_GO commands to acquire frames.<br /> <br /> This simplest example will acquire 1000 frames from rc2 into the file /data/cryo/current_data/test:<br /> acq_config /data/cryo/current_data/test rc2<br /> Line 1 : ok<br /> acq_go 1000<br /> Line 2 : ok<br /> <br /> The configuration commands have mnemonics that begin with "ACQ_CONFIG". They allow a small variety of output formats.<br /> <br /> === acq_config : configure simple MCE frame file ===<br /> <br /> The acq_config command configures a single output file to receive MCE frames.<br /> <br /> Syntax:<br /> acq_config <filename> <readout_card><br /> <br /> Example:<br /> acq_config test1.dat rc2<br /> <br /> === acq_config_fs : configure file-sequenced MCE frame file ===<br /> <br /> The acq_config_fs command will result in the outputting of the frame data into a set of files whose filename contains an increasing index. The output file is changed after <change_interval> frames. The output files will be called <filename>.000, <filename>.001, etc.<br /> <br /> Syntax:<br /> acq_config_fs <filename> <readout_card> <change_interval><br /> <br /> <br /> === acq_path : set the default path for data output ===<br /> <br /> The acq_path command sets the default output directory for frame data. This path is only appled if the filenames given in acq_config_* do not specify a relative path. The given path can be absolute, or relative to the mce_cmd's run-time working directory. The default output location can also be specified using the '-o' command line option.<br /> <br /> Syntax:<br /> acq_path <path><br /> <br /> Example:<br /> acq_path /data/cryo/current_data<br /> acq_config test1 rc1<br /> acq_go 10<br /> <br /> === acq_go : acquire frame data ===<br /> <br /> The acq_go command causes the MCE to begin acquiring data. The frame data will be stored according to the most recent acq_config* command. It is not usually necessary to reconfigure the output system (i.e. perform another acq_config) between acq_go commands. The exception to this is that if the frame structure changes (i.e. "cc num_rows_reported" is altered), then acq_config should be issued again so that the acquisition system can determine the frame size. <br /> <br /> Syntax:<br /> acq_go <frame_count><br /> <br /> Example:<br /> acq_config tes_bias_ramp rc1<br /> wb tes bias 5 5 5<br /> acq_go 1<br /> wb tes bias 10 10 10<br /> acq_go 1<br /> <br /> = Output formatting =<br /> <br /> The output consists of two or three parts, separated by colons. If in line prefix mode (which is the default) the output is:<br /> Line <line number>: <success> [: data ... ]<br /> <br /> The <success> indicator will be "ok" if the command succeeded, or "error" otherwise. Successful commands may return data (for example, an RB command). Failed commands will always return an error message as the data.<br /> <br /> If mce_cmd is invoked with prefixes turned off ('-p'), the output format is<br /> <success> [: data]<br /> <br /> If mce_cmd is invoked in quiet mode ('q'), then all command responses that have no output data are suppressed. In quiet mode, "Line 12: ok" will not be displayed.</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Mce_cmd&diff=1604 Mce cmd 2008-03-06T09:12:20Z

<p>Sysop: /* Output formatting */</p> <hr /> <div>= Introduction =<br /> <br /> mce_cmd provides an interface between a Linux shell and the MCE. The application can run interactively (accepting commands from a user and issuing responses to stdout), or can be used to execute scripts containing mce_cmd instructions.<br /> <br /> = Running mce_cmd =<br /> <br /> == Interactive mode ==<br /> <br /> When invoked with the '-i' option, mce_cmd can be used interactively. A session command history (similar to the one in bash) can be accessed with the up and down arrow keys, and line editing is possible using emacs-based key-mappings.<br /> mce_cmd -i<br /> <br /> After displaying a version message, mce_cmd will be ready to accept input. There is no user prompt.<br /> <br /> == Single command execution ==<br /> <br /> A single command can be issued using the '-x' option:<br /> mce_cmd -x rb cc fw_rev<br /> The application will execute the command, display any output, and exit. Currently, only single commands can be executed from the command line.<br /> <br /> == Script execution ==<br /> <br /> The '-f' option tell mce_cmd to read lines from the specified file and attempt to execute them. The '-q' option suppresses unnecessary output.<br /> mce_cmd -q -f my_script.scr<br /> <br /> When redirecting commands to mce_cmd, the '-r' option should be used to disable the command history/line editing features of mce_cmd and decrease the execution time.<br /> cat my_script.scr | mce_cmd -q -r<br /> <br /> If a script command fails, mce_cmd will exit. To suppress that behaviour (and continue attempting commands even after one of them has failed), pass the '-i' option.<br /> <br /> <br /> = Commands =<br /> <br /> We can break the mce_cmd command set into three broad categories: MCE commands, data acquisition commands, and output formatting commands.<br /> <br /> == MCE data block commands ==<br /> <br /> MCE configuration data is stored in blocks at certain card and parameter addresses (which we will call "block locations"). A typical block address is<br /> rc2 flx_quanta4<br /> This block consists of 41 32-bit words where the user writes the squid-1 flux quantum size for column 4 on readout card 2.<br /> <br /> The most basic data manipulation commands are RB ("read block") and WB<br /> ("write block"). These commands read from or write to the entire range of<br /> data at the block location, starting at the beginning of the block.<br /> <br /> The commands RRA ("read range") and WRA ("write range") can be used to<br /> read or write particular subranges of the data in a block location.<br /> <br /> All read and write commands take a card (or [[ Virtual cards | virtual card ]]) name and a<br /> parameter name as the first two arguments. <br /> <br /> === RB: read block ===<br /> <br /> The read block command returns the entire contents of a block location.<br /> <br /> Syntax:<br /> rb <card> <param><br /> Example:<br /> rb rc1 adc_offset0<br /> Line 1 : ok : 10 11 9 8 12 13 14 15<br /> <br /> <br /> === WB: write block ===<br /> <br /> The write block command writes the given data to the specified block location. If the number of data is smaller than block size, the remaining block elements will not be altered. If the number of data is larger than the block size, the behaviour depends on the implementation of the block location.<br /> <br /> Syntax:<br /> wb <card> <param> [val0 val1 val2 ...]<br /> Example:<br /> wb rc1 adc_offset0 0 1 2<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 12 13 14 15<br /> <br /> === RRA: read range ===<br /> <br /> The read range command returns <count> values from the block location, starting from the value at <start_index> (indexed from 0).<br /> <br /> Syntax:<br /> rra <card> <param> <start_index> <count><br /> Example:<br /> rra rc1 adc_offset0 2 4<br /> Line 1 : ok : 2 8 12 13<br /> <br /> === WRA: write range ===<br /> <br /> The write range command writes the given values into the block location, starting at <start_index> (indexed from 0). Other block data (i.e. at indices lower than start_index) are not changed. (This command is implemented as a read-update-write and will usually take twice as long to execute as a WB command.)<br /> <br /> Syntax:<br /> wra <card> <param> <start_index> [val0 val1 val2 ...]<br /> Example:<br /> wra rc1 adc_offset0 4 100 200<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 100 200 14 15<br /> <br /> == MCE data acquisition commands ==<br /> <br /> The acquisition of frame data is achieved by first configuring an output system (by specifying an output format, filename, and the target readout cards), and then by issuing ACQ_GO commands to acquire frames.<br /> <br /> This simplest example will acquire 1000 frames from rc2 into the file /data/cryo/current_data/test:<br /> acq_config /data/cryo/current_data/test rc2<br /> Line 1 : ok<br /> acq_go 1000<br /> Line 2 : ok<br /> <br /> The configuration commands have mnemonics that begin with "ACQ_CONFIG". They allow a small variety of output formats.<br /> <br /> === acq_config : configure simple MCE frame file ===<br /> <br /> The acq_config command configures a single output file to receive MCE frames.<br /> <br /> Syntax:<br /> acq_config <filename> <readout_card><br /> <br /> Example:<br /> acq_config test1.dat rc2<br /> <br /> === acq_config_fs : configure file-sequenced MCE frame file ===<br /> <br /> The acq_config_fs command will result in the outputting of the frame data into a set of files whose filename contains an increasing index. The output file is changed after <change_interval> frames. The output files will be called <filename>.000, <filename>.001, etc.<br /> <br /> Syntax:<br /> acq_config_fs <filename> <readout_card> <change_interval><br /> <br /> <br /> === acq_path : set the default path for data output ===<br /> <br /> The acq_path command sets the default output directory for frame data. This path is only appled if the filenames given in acq_config_* do not specify a relative path. The given path can be absolute, or relative to the mce_cmd's run-time working directory. The default output location can also be specified using the '-o' command line option.<br /> <br /> Syntax:<br /> acq_path <path><br /> <br /> Example:<br /> acq_path /data/cryo/current_data<br /> acq_config test1 rc1<br /> acq_go 10<br /> <br /> === acq_go : acquire frame data ===<br /> <br /> The acq_go command causes the MCE to begin acquiring data. The frame data will be stored according to the most recent acq_config* command. It is not usually necessary to reconfigure the output system (i.e. perform another acq_config) between acq_go commands. The exception to this is that if the frame structure changes (i.e. "cc num_rows_reported" is altered), then acq_config should be issued again so that the acquisition system can determine the frame size. <br /> <br /> Syntax:<br /> acq_go <frame_count><br /> <br /> Example:<br /> acq_config tes_bias_ramp rc1<br /> wb tes bias 5 5 5<br /> acq_go 1<br /> wb tes bias 10 10 10<br /> acq_go 1<br /> <br /> = Output formatting =<br /> <br /> The output consists of two or three parts, separated by colons. If in line prefix mode (which is the default) the output is:<br /> Line <line number>: <success> [: data ... ]<br /> <br /> The <success> indicator will be "ok" if the command succeeded, or "error" otherwise. Successful commands may return data (for example, an RB command). Failed commands will always return an error message as the data.<br /> <br /> If mce_cmd is invoked with prefixes turned off ('-p'), the output format is<br /> <success> [: auxiliary data]<br /> <br /> If mce_cmd is invoked in quiet mode ('q'), then all command responses that have no auxiliary data are suppressed. In quiet mode, "Line 12: ok" will not be displayed.</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Mce_cmd&diff=1603 Mce cmd 2008-03-06T08:18:18Z

<p>Sysop: /* Overview */</p> <hr /> <div>= Introduction =<br /> <br /> mce_cmd provides an interface between a Linux shell and the MCE. The application can run interactively (accepting commands from a user and issuing responses to stdout), or can be used to execute scripts containing mce_cmd instructions.<br /> <br /> = Running mce_cmd =<br /> <br /> == Interactive mode ==<br /> <br /> When invoked with the '-i' option, mce_cmd can be used interactively. A session command history (similar to the one in bash) can be accessed with the up and down arrow keys, and line editing is possible using emacs-based key-mappings.<br /> mce_cmd -i<br /> <br /> After displaying a version message, mce_cmd will be ready to accept input. There is no user prompt.<br /> <br /> == Single command execution ==<br /> <br /> A single command can be issued using the '-x' option:<br /> mce_cmd -x rb cc fw_rev<br /> The application will execute the command, display any output, and exit. Currently, only single commands can be executed from the command line.<br /> <br /> == Script execution ==<br /> <br /> The '-f' option tell mce_cmd to read lines from the specified file and attempt to execute them. The '-q' option suppresses unnecessary output.<br /> mce_cmd -q -f my_script.scr<br /> <br /> When redirecting commands to mce_cmd, the '-r' option should be used to disable the command history/line editing features of mce_cmd and decrease the execution time.<br /> cat my_script.scr | mce_cmd -q -r<br /> <br /> If a script command fails, mce_cmd will exit. To suppress that behaviour (and continue attempting commands even after one of them has failed), pass the '-i' option.<br /> <br /> <br /> = Commands =<br /> <br /> We can break the mce_cmd command set into three broad categories: MCE commands, data acquisition commands, and output formatting commands.<br /> <br /> == MCE data block commands ==<br /> <br /> MCE configuration data is stored in blocks at certain card and parameter addresses (which we will call "block locations"). A typical block address is<br /> rc2 flx_quanta4<br /> This block consists of 41 32-bit words where the user writes the squid-1 flux quantum size for column 4 on readout card 2.<br /> <br /> The most basic data manipulation commands are RB ("read block") and WB<br /> ("write block"). These commands read from or write to the entire range of<br /> data at the block location, starting at the beginning of the block.<br /> <br /> The commands RRA ("read range") and WRA ("write range") can be used to<br /> read or write particular subranges of the data in a block location.<br /> <br /> All read and write commands take a card (or [[ Virtual cards | virtual card ]]) name and a<br /> parameter name as the first two arguments. <br /> <br /> === RB: read block ===<br /> <br /> The read block command returns the entire contents of a block location.<br /> <br /> Syntax:<br /> rb <card> <param><br /> Example:<br /> rb rc1 adc_offset0<br /> Line 1 : ok : 10 11 9 8 12 13 14 15<br /> <br /> <br /> === WB: write block ===<br /> <br /> The write block command writes the given data to the specified block location. If the number of data is smaller than block size, the remaining block elements will not be altered. If the number of data is larger than the block size, the behaviour depends on the implementation of the block location.<br /> <br /> Syntax:<br /> wb <card> <param> [val0 val1 val2 ...]<br /> Example:<br /> wb rc1 adc_offset0 0 1 2<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 12 13 14 15<br /> <br /> === RRA: read range ===<br /> <br /> The read range command returns <count> values from the block location, starting from the value at <start_index> (indexed from 0).<br /> <br /> Syntax:<br /> rra <card> <param> <start_index> <count><br /> Example:<br /> rra rc1 adc_offset0 2 4<br /> Line 1 : ok : 2 8 12 13<br /> <br /> === WRA: write range ===<br /> <br /> The write range command writes the given values into the block location, starting at <start_index> (indexed from 0). Other block data (i.e. at indices lower than start_index) are not changed. (This command is implemented as a read-update-write and will usually take twice as long to execute as a WB command.)<br /> <br /> Syntax:<br /> wra <card> <param> <start_index> [val0 val1 val2 ...]<br /> Example:<br /> wra rc1 adc_offset0 4 100 200<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 100 200 14 15<br /> <br /> == MCE data acquisition commands ==<br /> <br /> The acquisition of frame data is achieved by first configuring an output system (by specifying an output format, filename, and the target readout cards), and then by issuing ACQ_GO commands to acquire frames.<br /> <br /> This simplest example will acquire 1000 frames from rc2 into the file /data/cryo/current_data/test:<br /> acq_config /data/cryo/current_data/test rc2<br /> Line 1 : ok<br /> acq_go 1000<br /> Line 2 : ok<br /> <br /> The configuration commands have mnemonics that begin with "ACQ_CONFIG". They allow a small variety of output formats.<br /> <br /> === acq_config : configure simple MCE frame file ===<br /> <br /> The acq_config command configures a single output file to receive MCE frames.<br /> <br /> Syntax:<br /> acq_config <filename> <readout_card><br /> <br /> Example:<br /> acq_config test1.dat rc2<br /> <br /> === acq_config_fs : configure file-sequenced MCE frame file ===<br /> <br /> The acq_config_fs command will result in the outputting of the frame data into a set of files whose filename contains an increasing index. The output file is changed after <change_interval> frames. The output files will be called <filename>.000, <filename>.001, etc.<br /> <br /> Syntax:<br /> acq_config_fs <filename> <readout_card> <change_interval><br /> <br /> <br /> === acq_path : set the default path for data output ===<br /> <br /> The acq_path command sets the default output directory for frame data. This path is only appled if the filenames given in acq_config_* do not specify a relative path. The given path can be absolute, or relative to the mce_cmd's run-time working directory. The default output location can also be specified using the '-o' command line option.<br /> <br /> Syntax:<br /> acq_path <path><br /> <br /> Example:<br /> acq_path /data/cryo/current_data<br /> acq_config test1 rc1<br /> acq_go 10<br /> <br /> === acq_go : acquire frame data ===<br /> <br /> The acq_go command causes the MCE to begin acquiring data. The frame data will be stored according to the most recent acq_config* command. It is not usually necessary to reconfigure the output system (i.e. perform another acq_config) between acq_go commands. The exception to this is that if the frame structure changes (i.e. "cc num_rows_reported" is altered), then acq_config should be issued again so that the acquisition system can determine the frame size. <br /> <br /> Syntax:<br /> acq_go <frame_count><br /> <br /> Example:<br /> acq_config tes_bias_ramp rc1<br /> wb tes bias 5 5 5<br /> acq_go 1<br /> wb tes bias 10 10 10<br /> acq_go 1<br /> <br /> = Output formatting =<br /> <br /> The output consists of two or three parts, separated by colons. If in line prefix mode (which is the default) the output is:<br /> Line <line number>: <success> [: auxiliary data]<br /> <br /> The <success> indicator will be "ok" if the command succeeded, or "error" otherwise. Successful commands may return data (for example, an RB command). Failed commands will always return an error message as the auxiliary data.<br /> <br /> If mce_cmd is invoked with prefixes turned off ('-p'), the output format is<br /> <success> [: auxiliary data]<br /> <br /> If mce_cmd is invoked in quiet mode ('q'), then all command responses that have no auxiliary data are suppressed. In quiet mode, "Line 12: ok" will not be displayed.</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Mce_cmd&diff=1602 Mce cmd 2008-03-06T08:16:02Z

<p>Sysop: /* MCE data block commands */</p> <hr /> <div>= Overview =<br /> <br /> mce_cmd provides an interface between a linux shell and the MCE. The application can run interactively (accepting commands from a user and issuing responses to standard out), or can be used to execute scripts containing mce_cmd instructions.<br /> <br /> = Running mce_cmd =<br /> <br /> == Interactive mode ==<br /> <br /> When invoked with the '-i' option, mce_cmd can be used interactively. A session command history (similar to the one in bash) can be accessed with the up and down arrow keys, and line editing is possible using emacs-based key-mappings.<br /> mce_cmd -i<br /> <br /> After displaying a version message, mce_cmd will be ready to accept input. There is no user prompt.<br /> <br /> == Single command execution ==<br /> <br /> A single command can be issued using the '-x' option:<br /> mce_cmd -x rb cc fw_rev<br /> The application will execute the command, display any output, and exit. Currently, only single commands can be executed from the command line.<br /> <br /> == Script execution ==<br /> <br /> The '-f' option tell mce_cmd to read lines from the specified file and attempt to execute them. The '-q' option suppresses unnecessary output.<br /> mce_cmd -q -f my_script.scr<br /> <br /> When redirecting commands to mce_cmd, the '-r' option should be used to disable the command history/line editing features of mce_cmd and decrease the execution time.<br /> cat my_script.scr | mce_cmd -q -r<br /> <br /> If a script command fails, mce_cmd will exit. To suppress that behaviour (and continue attempting commands even after one of them has failed), pass the '-i' option.<br /> <br /> <br /> = Commands =<br /> <br /> We can break the mce_cmd command set into three broad categories: MCE commands, data acquisition commands, and output formatting commands.<br /> <br /> == MCE data block commands ==<br /> <br /> MCE configuration data is stored in blocks at certain card and parameter addresses (which we will call "block locations"). A typical block address is<br /> rc2 flx_quanta4<br /> This block consists of 41 32-bit words where the user writes the squid-1 flux quantum size for column 4 on readout card 2.<br /> <br /> The most basic data manipulation commands are RB ("read block") and WB<br /> ("write block"). These commands read from or write to the entire range of<br /> data at the block location, starting at the beginning of the block.<br /> <br /> The commands RRA ("read range") and WRA ("write range") can be used to<br /> read or write particular subranges of the data in a block location.<br /> <br /> All read and write commands take a card (or [[ Virtual cards | virtual card ]]) name and a<br /> parameter name as the first two arguments. <br /> <br /> === RB: read block ===<br /> <br /> The read block command returns the entire contents of a block location.<br /> <br /> Syntax:<br /> rb <card> <param><br /> Example:<br /> rb rc1 adc_offset0<br /> Line 1 : ok : 10 11 9 8 12 13 14 15<br /> <br /> <br /> === WB: write block ===<br /> <br /> The write block command writes the given data to the specified block location. If the number of data is smaller than block size, the remaining block elements will not be altered. If the number of data is larger than the block size, the behaviour depends on the implementation of the block location.<br /> <br /> Syntax:<br /> wb <card> <param> [val0 val1 val2 ...]<br /> Example:<br /> wb rc1 adc_offset0 0 1 2<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 12 13 14 15<br /> <br /> === RRA: read range ===<br /> <br /> The read range command returns <count> values from the block location, starting from the value at <start_index> (indexed from 0).<br /> <br /> Syntax:<br /> rra <card> <param> <start_index> <count><br /> Example:<br /> rra rc1 adc_offset0 2 4<br /> Line 1 : ok : 2 8 12 13<br /> <br /> === WRA: write range ===<br /> <br /> The write range command writes the given values into the block location, starting at <start_index> (indexed from 0). Other block data (i.e. at indices lower than start_index) are not changed. (This command is implemented as a read-update-write and will usually take twice as long to execute as a WB command.)<br /> <br /> Syntax:<br /> wra <card> <param> <start_index> [val0 val1 val2 ...]<br /> Example:<br /> wra rc1 adc_offset0 4 100 200<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 100 200 14 15<br /> <br /> == MCE data acquisition commands ==<br /> <br /> The acquisition of frame data is achieved by first configuring an output system (by specifying an output format, filename, and the target readout cards), and then by issuing ACQ_GO commands to acquire frames.<br /> <br /> This simplest example will acquire 1000 frames from rc2 into the file /data/cryo/current_data/test:<br /> acq_config /data/cryo/current_data/test rc2<br /> Line 1 : ok<br /> acq_go 1000<br /> Line 2 : ok<br /> <br /> The configuration commands have mnemonics that begin with "ACQ_CONFIG". They allow a small variety of output formats.<br /> <br /> === acq_config : configure simple MCE frame file ===<br /> <br /> The acq_config command configures a single output file to receive MCE frames.<br /> <br /> Syntax:<br /> acq_config <filename> <readout_card><br /> <br /> Example:<br /> acq_config test1.dat rc2<br /> <br /> === acq_config_fs : configure file-sequenced MCE frame file ===<br /> <br /> The acq_config_fs command will result in the outputting of the frame data into a set of files whose filename contains an increasing index. The output file is changed after <change_interval> frames. The output files will be called <filename>.000, <filename>.001, etc.<br /> <br /> Syntax:<br /> acq_config_fs <filename> <readout_card> <change_interval><br /> <br /> <br /> === acq_path : set the default path for data output ===<br /> <br /> The acq_path command sets the default output directory for frame data. This path is only appled if the filenames given in acq_config_* do not specify a relative path. The given path can be absolute, or relative to the mce_cmd's run-time working directory. The default output location can also be specified using the '-o' command line option.<br /> <br /> Syntax:<br /> acq_path <path><br /> <br /> Example:<br /> acq_path /data/cryo/current_data<br /> acq_config test1 rc1<br /> acq_go 10<br /> <br /> === acq_go : acquire frame data ===<br /> <br /> The acq_go command causes the MCE to begin acquiring data. The frame data will be stored according to the most recent acq_config* command. It is not usually necessary to reconfigure the output system (i.e. perform another acq_config) between acq_go commands. The exception to this is that if the frame structure changes (i.e. "cc num_rows_reported" is altered), then acq_config should be issued again so that the acquisition system can determine the frame size. <br /> <br /> Syntax:<br /> acq_go <frame_count><br /> <br /> Example:<br /> acq_config tes_bias_ramp rc1<br /> wb tes bias 5 5 5<br /> acq_go 1<br /> wb tes bias 10 10 10<br /> acq_go 1<br /> <br /> = Output formatting =<br /> <br /> The output consists of two or three parts, separated by colons. If in line prefix mode (which is the default) the output is:<br /> Line <line number>: <success> [: auxiliary data]<br /> <br /> The <success> indicator will be "ok" if the command succeeded, or "error" otherwise. Successful commands may return data (for example, an RB command). Failed commands will always return an error message as the auxiliary data.<br /> <br /> If mce_cmd is invoked with prefixes turned off ('-p'), the output format is<br /> <success> [: auxiliary data]<br /> <br /> If mce_cmd is invoked in quiet mode ('q'), then all command responses that have no auxiliary data are suppressed. In quiet mode, "Line 12: ok" will not be displayed.</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Mce_cmd&diff=1601 Mce cmd 2008-03-06T07:51:50Z

<p>Sysop: </p> <hr /> <div>= Overview =<br /> <br /> mce_cmd provides an interface between a linux shell and the MCE. The application can run interactively (accepting commands from a user and issuing responses to standard out), or can be used to execute scripts containing mce_cmd instructions.<br /> <br /> = Running mce_cmd =<br /> <br /> == Interactive mode ==<br /> <br /> When invoked with the '-i' option, mce_cmd can be used interactively. A session command history (similar to the one in bash) can be accessed with the up and down arrow keys, and line editing is possible using emacs-based key-mappings.<br /> mce_cmd -i<br /> <br /> After displaying a version message, mce_cmd will be ready to accept input. There is no user prompt.<br /> <br /> == Single command execution ==<br /> <br /> A single command can be issued using the '-x' option:<br /> mce_cmd -x rb cc fw_rev<br /> The application will execute the command, display any output, and exit. Currently, only single commands can be executed from the command line.<br /> <br /> == Script execution ==<br /> <br /> The '-f' option tell mce_cmd to read lines from the specified file and attempt to execute them. The '-q' option suppresses unnecessary output.<br /> mce_cmd -q -f my_script.scr<br /> <br /> When redirecting commands to mce_cmd, the '-r' option should be used to disable the command history/line editing features of mce_cmd and decrease the execution time.<br /> cat my_script.scr | mce_cmd -q -r<br /> <br /> If a script command fails, mce_cmd will exit. To suppress that behaviour (and continue attempting commands even after one of them has failed), pass the '-i' option.<br /> <br /> <br /> = Commands =<br /> <br /> We can break the mce_cmd command set into three broad categories: MCE commands, data acquisition commands, and output formatting commands.<br /> <br /> == MCE data block commands ==<br /> <br /> MCE configuration data is stored in blocks at certain card and parameter addresses (which we will call "block locations"). A typical block address is<br /> rc2 flx_quanta4<br /> This block consists of 41 32-bit words where the user writes the squid-1 flux quantum size for column 4 on readout card 2.<br /> <br /> The most basic data manipulation commands are RB ("read block") and WB<br /> ("write block"). These commands read from or write to the entire range of<br /> data at the block location, starting at the beginning of the block.<br /> <br /> The commands RRA ("read range") and WRA ("write range") can be used to<br /> read or write particular subranges of the data in a block location.<br /> <br /> All read and write commands take a card (or [[ Virtual cards | virtual card ]]) name and a<br /> parameter name as the first two arguments. <br /> <br /> === RB: read block ===<br /> <br /> Syntax:<br /> rb <card> <param><br /> <br /> The read block command returns the entire contents of a block location.<br /> <br /> Example:<br /> rb rc1 adc_offset0<br /> Line 1 : ok : 10 11 9 8 12 13 14 15<br /> <br /> <br /> === WB: write block ===<br /> <br /> Syntax:<br /> wb <card> <param> [val0 val1 val2 ...]<br /> <br /> The write block command writes the given data to the specified block location. If the number of data is smaller than block size, the remaining block elements will not be altered. If the number of data is larger than the block size, the behaviour depends on the implementation of the block location.<br /> <br /> Example:<br /> wb rc1 adc_offset0 0 1 2<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 12 13 14 15<br /> <br /> === RRA: read range ===<br /> <br /> Syntax:<br /> rra <card> <param> <start_index> <count><br /> <br /> The read range command returns <count> values from the block location, starting from the value at <start_index> (indexed from 0).<br /> <br /> Example:<br /> rra rc1 adc_offset0 2 4<br /> Line 1 : ok : 2 8 12 13<br /> <br /> === WRA: write range ===<br /> <br /> Syntax:<br /> wra <card> <param> <start_index> [val0 val1 val2 ...]<br /> <br /> The write range command writes the given values into the block location, starting at <start_index> (indexed from 0). Other block data (i.e. at indices lower than start_index) are not changed. (This command is implemented as a read-update-write and will usually take twice as long to execute as a WB command.)<br /> <br /> Example:<br /> wra rc1 adc_offset0 4 100 200<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 100 200 14 15<br /> <br /> <br /> = Output formatting =<br /> <br /> The output consists of two or three parts, separated by colons. If in line prefix mode (which is the default) the output is:<br /> Line <line number>: <success> [: auxiliary data]<br /> <br /> The <success> indicator will be "ok" if the command succeeded, or "error" otherwise. Successful commands may return data (for example, an RB command). Failed commands will always return an error message as the auxiliary data.<br /> <br /> If mce_cmd is invoked with prefixes turned off ('-p'), the output format is<br /> <success> [: auxiliary data]<br /> <br /> If mce_cmd is invoked in quiet mode ('q'), then all command responses that have no auxiliary data are suppressed. In quiet mode, "Line 12: ok" will not be displayed.</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS&diff=1600 MAS 2008-03-06T07:18:54Z

<p>Sysop: </p> <hr /> <div>== Usage ==<br /> <br /> * System applications<br /> ** [[mce_cmd]]<br /> ** [[mce_status]]<br /> ** [[maslog]]<br /> ** [[dsp_cmd]]<br /> ** [[ MAS Command line how-to ]]<br /> <br /> * Utilities<br /> <br /> * MAS configuration<br /> ** [[ MAS start/stop ]]<br /> ** [[ mce.cfg ]]<br /> ** [[ mas.cfg ]]<br /> <br /> * MAS file formats<br /> ** [[ Runfile format v2 ]]<br /> <br /> <br /> == Development ==<br /> <br /> * [[ MAS Bug List ]]<br /> * [[ MAS to-do ]]<br /> * [[ MAS feature requests ]]<br /> <br /> == Installation / configuration ==<br /> <br /> * [[ MAS PC requirements and initial setup | PC requirements and initial setup]]<br /> * [[ MAS OS setup | OS setup]]<br /> * [[ MAS kernel patch compilation | kernel patch compilation]]<br /> * [[ MAS svn repository | SVN repository]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Mce_cmd&diff=1599 Mce cmd 2008-03-06T07:11:29Z

<p>Sysop: /* Output formatting */</p> <hr /> <div>= Read and write commands =<br /> <br /> MCE configuration data is stored in blocks at certain card and<br /> parameter addresses (which we will call "block locations". The data<br /> block consists of one or more 32-bit words.<br /> <br /> The most basic data manipulation commands are RB ("read block") and WB<br /> ("write block"). These commands read and write to the entire range of<br /> data at the block location, starting at the beginning of the block.<br /> <br /> The commands RRA ("read range") and WRA ("write range") can be used to<br /> read or write particular subranges of the data in a block location.<br /> <br /> All read and write commands take a card (or virtual card) name and a<br /> parameter name as the first two arguments. Physical cards are<br /> associated with particular hardware elements in the system, for<br /> example "cc" (clock card) and "rc2" (readout card). Virtual cards are<br /> used to group a set of hardware functions into a single name-space.<br /> The data associated with a virtual card parameter may be shared across<br /> multiple hardware cards. Parameters accessible via virtual mappings<br /> are also accessible via some set of hardware card addresses.<br /> <br /> == Syntax summary ==<br /> <br /> rb <card> <param><br /> rra <card> <param> <starting index> <count><br /> wb <card> <param> [data, ...]<br /> wra <card> <param> <starting index> [data, ...]<br /> <br /> == RB command ==<br /> <br /> RB will return all data associated with the block location.<br /> <br /> rb rc1 adc_offset0<br /> Line 1 : ok : 10 11 9 8 12 13 14 15<br /> <br /> == RRA command ==<br /> <br /> The RRA command returns only the subset of the data that were<br /> asked for.<br /> <br /> rra rc1 adc_offset0 2 4<br /> Line 1 : ok : 9 8 12 13<br /> <br /> == WB command ==<br /> <br /> The WB command will update words in the block location. If the number<br /> of data words given as arguments to the WB command is smaller than the<br /> natural size of the block location, only those first few data<br /> locations will be updated. e.g.,<br /> <br /> wb rc1 adc_offset0 0 1 2<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 12 13 14 15<br /> <br /> == WRA command ==<br /> <br /> The WRA command updates words starting at the specified index.<br /> <br /> wra rc1 adc_offset0 4 100 200<br /> Line 1 : ok<br /> rb rc1 adc_offset0<br /> Line 2 : ok : 0 1 2 8 100 200 14 15<br /> Please note that WRA and RRA are not more efficient than WB and RB.<br /> MAS translates WRA and RRA into the equivalent set of WB and RB<br /> commands, and not the other way around.<br /> <br /> <br /> = Output formatting =<br /> <br /> The output consists of two or three parts, separated by colons. If in line prefix mode (which is the default) the output is:<br /> Line <line number>: <success> [: auxiliary data]<br /> <br /> The <success> indicator will be "ok" if the command succeeded, or "error" otherwise. Successful commands may return data (for example, an RB command). Failed commands will always return an error message as the auxiliary data.<br /> <br /> If mce_cmd is invoked with prefixes turned off ('-p'), the output format is<br /> <success> [: auxiliary data]<br /> <br /> If mce_cmd is invoked in quiet mode ('q'), then all command responses that have no auxiliary data are suppressed. In quiet mode, "Line 12: ok" will not be displayed.</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Virtual_card&diff=1598 Virtual card 2008-03-06T05:41:49Z

<p>Sysop: </p> <hr /> <div>== Description ==<br /> <br /> Unlike hardware (or "physical" cards), virtual cards are associated<br /> with a certain function (such as a squid amplifier stage). A single<br /> virtual card, parameter address can span multiple physical cards.<br /> <br /> Currently, the virtual cards implemented in mas are:<br /> <br /> sq1 First stage squid control (fb_const, bias, servo_mode)<br /> sq2 Second stage squid control (fb, bias)<br /> sa Series array control (fb, bias, offset)<br /> tes Detector and heater control (bias)<br /> <br /> Virtual cards are useful for two reasons. The first is to provide the<br /> user with a more intuitive mnemonic set. The second is to provide a<br /> layer of abstraction between function and hardware; this allows higher<br /> level programs and scripts to be written that are independent of the<br /> hardware configuration.<br /> <br /> Where possible, virtual card addresses should be used instead of<br /> hardware card addresses.<br /> <br /> Many virtual card parameters are shared across multiple hardware cards<br /> (usually, these are per-column parameters shared across all the<br /> readout cards). In this case, the virtual card data is assembled from<br /> each readout card, starting with rc1. For example, compare<br /> <br /> rb rc1 sa_bias<br /> Line 1 : ok : 0 1 2 3 4 5 6 7<br /> rb rc2 sa_bias<br /> Line 2 : ok : 8 9 10 11 12 13 14 15<br /> rb rc3 sa_bias<br /> Line 3 : ok : 16 17 18 19 20 21 22 23<br /> rb rc4 sa_bias<br /> Line 4 : ok : 24 25 26 27 28 29 30 31<br /> <br /> to<br /> <br /> rb sa bias<br /> Line 5 : ok : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31<br /> <br /> <br /> == Support for virtual card addresses ==<br /> <br /> The virtual card abstraction layer is provided by mce_library. The virtual cards are accessible to a scripting / interactive user through mce_cmd.<br /> <br /> Each subrack configuration has an associated mce.cfg file (which lives in /etc/mce/) which describes the hardware cards present in the system and the mapping from virtual addresses to hardware addresses. (This file should not require regular editing!)<br /> <br /> == Sub-rack version and population variation ==<br /> <br /> Many virtual addresses possess (on a full sub-rack) 32 values, one for each column of a<br /> squid array. In v2 systems, which have at most 2 readout cards (and thus at most 16<br /> columns of squids), such parameters will only return 16 values. However, in systems with<br /> empty readout card slots, virtual addresses will read out at full width (as if the rack was<br /> completely populated), but with any missing readout cards' columns padded with zeros.<br /> Writes to those missing columns will be ignored and not cause failures.<br /> <br /> This means that, for example, the 8 values of "rc2 sa_bias" always corresponds to the second set of 8 values in "sa bias" regardless of whether the system possesses rc1. <br /> <br /> == Commanding virtual cards ==<br /> <br /> Only read and write commands are supported on virtual cards. The RB,<br /> WB, RRA, and WRA all have the natural behaviour when operating on<br /> virtual cards. For example, the following are equivalent:<br /> <br /> rra bc3 bias 10 4<br /> rra sq2 bias 10 4<br /> <br /> For TES bias lines, the mapping will depend on the experiment's<br /> needs. By default, the parameter "tes bias" is a 3 word block that<br /> maps to "bc1 bias", "bc2 bias", and "bc3 bias".<br /> <br /> == Detail of mappings ==<br /> <br /> To get a list of the mappings on your system, run<br /> mce_status -g<br /> (When invoked with the '-g' option, mce_status will not issue MCE commands and no MCE or SDSU PCI card need be present.)<br /> <br /> For a description of the output formatting, see [[ mce_status ]].</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=Virtual_card&diff=1597 Virtual card 2008-03-06T05:08:13Z

<p>Sysop: </p> <hr /> <div>Unlike hardware (or "physical" cards), virtual cards are associated<br /> with a certain function (such as a squid amplifier stage). A single<br /> virtual card, parameter address can span multiple physical cards.<br /> <br /> Currently, the virtual cards implemented in mas are:<br /> <br /> sq1 First stage squid control (fb_const, bias, servo_mode)<br /> sq2 Second stage squid control (fb, bias)<br /> sa Series array control (fb, bias, offset)<br /> tes Detector and heater control (bias)<br /> <br /> Virtual cards are useful for two reasons. The first is to provide the<br /> user with a more intuitive mnemonic set. The second is to provide a<br /> layer of abstraction between function and hardware; this allows higher<br /> level programs and scripts to be written that are independent of the<br /> hardware configuration.<br /> <br /> Where possible, virtual card addresses should be used instead of<br /> hardware card addresses.<br /> <br /> == Reading and writing virtual cards ==<br /> <br /> Only read and write commands are supported on virtual cards. The RB,<br /> WB, RRA, and WRA all have the natural behaviour when operating on<br /> virtual cards. For example, the following are equivalent:<br /> <br /> rra bc3 bias 10 4<br /> rra sq2 bias 10 4<br /> <br /> Many virtual card parameters are shared across multiple hardware cards<br /> (usually, these are per-column parameters shared across all the<br /> readout cards). In this case, the virtual card data is assembled from<br /> each readout card, starting with rc1. For example, compare<br /> sq2 Second stage squid control (fb, bias)<br /> sa Series array control (fb, bias, offset)<br /> tes Detector and heater control (bias)<br /> <br /> Virtual cards are useful for two reasons. The first is to provide the<br /> user with a more intuitive mnemonic set. The second is to provide a<br /> layer of abstraction between function and hardware; this allows higher<br /> level programs and scripts to be written that are independent of the<br /> hardware configuration.<br /> <br /> Where possible, virtual card addresses should be used instead of<br /> hardware card addresses.<br /> <br /> == Reading and writing virtual cards ==<br /> <br /> Only read and write commands are supported on virtual cards. The RB,<br /> WB, RRA, and WRA all have the natural behaviour when operating on<br /> virtual cards. For example, the following are equivalent:<br /> <br /> rra bc3 bias 10 4<br /> rra sq2 bias 10 4<br /> <br /> Many virtual card parameters are shared across multiple hardware cards<br /> (usually, these are per-column parameters shared across all the<br /> readout cards). In this case, the virtual card data is assembled from<br /> each readout card, starting with rc1. For example, compare<br /> <br /> rb rc1 sa_bias<br /> Line 1 : ok : 0 1 2 3 4 5 6 7<br /> rb rc2 sa_bias<br /> Line 2 : ok : 8 9 10 11 12 13 14 15<br /> rb rc3 sa_bias<br /> Line 3 : ok : 16 17 18 19 20 21 22 23<br /> rb rc4 sa_bias<br /> Line 4 : ok : 24 25 26 27 28 29 30 31<br /> <br /> to<br /> <br /> rb sa bias<br /> Line 5 : ok : 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31<br /> <br /> (In v2 systems, which can only hold 2 readout cards, such parameters<br /> will only return 16 values. In systems with empty readout card slots,<br /> the data in virtual card parameters will be padded to account for the<br /> missing cards.)<br /> <br /> For TES bias lines, the mapping will depend on the experiment's<br /> needs. By default, the parameter "tes bias" is a 3 word block that<br /> maps to "bc1 bias", "bc2 bias", and "bc3 bias".<br /> <br /> == Detail of mappings ==<br /> <br /> To get a list of the mappings on your system, run mce_status with the<br /> -g option. (This does not require an MCE to be connected, and it will<br /> not issue any MCE commands.)<br /> <br /> The output from "mce_status -g" is interpreted as follows...</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS&diff=1591 MAS 2008-03-05T22:42:07Z

<p>Sysop: /* Installation / configuration */</p> <hr /> <div>* [[ MAS Overview ]]<br /> <br /> = Development =<br /> <br /> * [[ MAS Bug List ]]<br /> * [[ MAS to-do ]]<br /> * [[ MAS feature requests ]]<br /> <br /> = Installation / configuration =<br /> <br /> * [[ MAS PC requirements and initial setup | PC requirements and initial setup]]<br /> * [[ MAS OS setup | OS setup]]<br /> * [[ MAS kernel patch compilation | kernel patch compilation]]<br /> * [[ MAS svn repository | SVN repository]]<br /> <br /> = Usage =<br /> <br /> * [[ MAS start/stop ]]<br /> * [[ MAS Command line how-to ]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS_OS_setup&diff=1589 MAS OS setup 2008-03-05T22:40:16Z

<p>Sysop: MAS installation notes moved to MAS OS setup</p> <hr /> <div>= Install additional ubuntu packages =<br /> <br /> == Disable CDROM seeking ==<br /> <br /> The package manager knows that you have the Ubuntu disk and will say things like<br /> Media change: please insert the disc labeled<br /> 'Ubuntu-Server 6.06.1 _Dapper Drake_ - Release i386 (20060807.1)'<br /> <br /> To disable this (and download packages from the internet instead), open /etc/apt/sources.list and remove (comment) the line <br /> deb cdrom:[Ubuntu-Server 6.06.1 _Dapper Drake_ - Release i386 (20060807.1)]/ dapper main restricted<br /> <br /> and then do<br /> apt-get sudo update<br /> <br /> <br /> == Install required packages ==<br /> <br /> sudo apt-get update<br /> sudo apt-get install build-essential subversion emacs21 libreadline5-dev <br /> <br /> == Try to install packages that don't work properly (impossible) ==<br /> <br /> sudo apt-get install gnome-gv<br /> <br /> == Install packages that you shouldn't even want to install (optional) ==<br /> sudo apt-get install tcsh<br /> <br /> <br /> = Download and install MAS kernel patch =<br /> <br /> == Download ==<br /> <br /> If you're not compiling the kernel from scratch, download the binary packages from UBC:<br /> wget http://e-mode.phas.ubc.ca/~mhasse/mce/kernel-headers-2.6.15.7-bigphys_10.00.Custom_i386.deb<br /> wget http://e-mode.phas.ubc.ca/~mhasse/mce/kernel-image-2.6.15.7-bigphys_10.00.Custom_i386.deb<br /> wget http://e-mode.phas.ubc.ca/~mhasse/mce/extras.patch<br /> <br /> == Install ==<br /> <br /> Then, install the packages using dpkg:<br /> sudo dpkg -i kernel-headers-2.6.15.7-bigphys_10.00.Custom_i386.deb<br /> sudo dpkg -i kernel-image-2.6.15.7-bigphys_10.00.Custom_i386.deb<br /> The "image" file might complain about symbolic links, no big deal.<br /> <br /> == Patch ==<br /> <br /> This makes it possible to compile against the kernel package as though it had been locally compiled originally.<br /> cd /usr/src/kernel-headers-2.6.15.7-bigphys/<br /> sudo patch < ~/extras.patch<br /> <br /> == Boot menu ==<br /> <br /> Once you install the "image", the kernel should show up in the boot loader (grub)'s kernel list. It's probably a good idea to test it first before setting it as the default kernel (see next step). Also *do not issue MCE or DSP commands until the acpi=off boot parameter has been configured!*<br /> <br /> <br /> <br /> = Configure GRUB boot menu =<br /> <br /> As root (or using sudo), edit the file /boot/grub/menu.lst . Go to the list of kernels, below the line "## ## End Default Options ##", and find the kernel block with title "Ubuntu, kernel 2.6.15.7-bigphys". It should be the third block in the list, i.e. index 2.<br /> <br /> You must change the kernel line to turn "acpi=off". Almost all systems crash hard if you don't do this.<br /> <br /> kernel /vmlinuz-2.6.15.7-bigphys root=/dev/sda3 ro quiet splash acpi=off bigphysarea=8192<br /> <br /> Go back to the top of the file and set the value of the "default" option to 2 once you're ready to boot this kernel by default.<br /> <br /> <br /> = External libraries =<br /> <br /> MAS uses libconfig to manage its configuration files. The webpage is here: [ http://www.hyperrealm.com/libconfig/ ]. To install libconfig run the following:<br /> <br /> wget http://www.hyperrealm.com/libconfig/libconfig-1.2.1.tar.gz<br /> tar -xzf libconfig-1.2.1.tar.gz<br /> cd libconfig-1.2.1<br /> ./configure<br /> make<br /> sudo make install<br /> <br /> To make the system aware of this library, add "/usr/local/lib" to /etc/ld.so.conf and run "sudo ldconfig". i.e.<br /> echo /usr/local/lib | sudo tee /etc/ld.so.conf<br /> sudo ldconfig<br /> <br /> = Branching of MAS and mce_script =<br /> <br /> From a complete (or somewhat complete) mas source tree (i.e. the repository root) do:<br /> <br /> svn copy trunk branch/new_project<br /> svn commit branch/new_project<br /> <br /> Then check out the appropriate branch (or the whole tree) on the new machine.<br /> <br /> = Download MAS =<br /> <br /> See the page on [[ MAS svn repository ]]<br /> <br /> = Build the driver =<br /> <br /> There are some compilation options that must be enabled before compiling the driver. This is achieved by putting the definitions into a file Makefile.local in the "driver" folder.<br /> <br /> For a normal MAS install, with bigphysarea enabled, Makefile.local should contain only the line<br /> BIGPHYS = 1 # use bigphysarea for frame buffering<br /> <br /> Other options one can put in Makefile.local are<br /> FAKEMCE = 1 # enable software MCE emulator in driver<br /> and<br /> REALTIME = 1 # use rtai interrupt handling<br /> <br /> Um, you probably shouldn't use these. Just use BIGPHYS.<br /> <br /> Anyway, once Makefile.local is setup, type<br /> make clean; make<br /> <br /> From the driver folder we can test the driver:<br /> ./reload<br /> ./mknodes<br /> <br /> Note that since "reload" first unloads the driver if it is present, and then loads the driver from the current folder, it may report an "ERROR" message if the first step fails, even though the driver is successfully loaded. The definitive way to check that the driver is loaded is<br /> cat /proc/mce_dsp<br /> <br /> If this file does not exist, the driver isn't loaded. If the cat prints out a bunch of low-level driver information, you're in good shape.<br /> <br /> If you're satisfied that the driver works, install the driver with the command<br /> <br /> sudo make install<br /> <br /> This should put mce_dsp.ko into /lib/modules/2.6.15.7-bigphys/kernel/drivers/misc/, and re-scan the module dependencies. To get the driver to load on boot you must add manually the following lines to /etc/rc.local:<br /> <br /> modprobe mce_dsp<br /> /home/mce/mas/driver/mknodes<br /> sudo -u mce /usr/mce/bin/maslog_server<br /> <br /> = Install MAS (double check)= <br /> cd /home/mce/mas and type<br /> make install <br /> (would this include servo programs??)<br /> <br /> = Folders =<br /> <br /> sudo mkdir /data<br /> sudo chown mce:mce /data<br /> sudo chmod g+ws /data<br /> <br /> mkdir /home/mce/tmp<br /> chmod g+ws /home/mce/tmp<br /> <br /> Folder permissions are annoying. Basically, any place you're going to be creating files has to have the g+s bit set. svn folders are particularly bad...<br /> <br /> chmod g+ws /home/mce<br /> chmod g+ws /home/mce/script<br /> chmod g+ws /home</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS_installation_notes&diff=1590 MAS installation notes 2008-03-05T22:40:16Z

<p>Sysop: MAS installation notes moved to MAS OS setup</p> <hr /> <div>#REDIRECT [[MAS OS setup]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS&diff=1588 MAS 2008-03-05T22:40:02Z

<p>Sysop: /* Installation / configuration */</p> <hr /> <div>* [[ MAS Overview ]]<br /> <br /> = Development =<br /> <br /> * [[ MAS Bug List ]]<br /> * [[ MAS to-do ]]<br /> * [[ MAS feature requests ]]<br /> <br /> = Installation / configuration =<br /> <br /> * [[ MAS PC requirements and initial setup ]]<br /> * [[ MAS installation notes ]]<br /> * [[ MAS OS configuration ]]<br /> * [[ MAS svn repository ]]<br /> <br /> = Usage =<br /> <br /> * [[ MAS start/stop ]]<br /> * [[ MAS Command line how-to ]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS_kernel_patch_compilation&diff=1587 MAS kernel patch compilation 2008-03-05T22:32:21Z

<p>Sysop: </p> <hr /> <div>This procedure is based on<br /> <br /> http://www.howtoforge.com/kernel_compilation_ubuntu<br /> <br /> <br /> == Get linux sources ==<br /> <br /> We use vanilla 2.6.15.7, vanilla, from kernel.org.<br /> <br /> == Get bigphys patch ==<br /> <br /> Patch is available here:<br /> http://e-mode.phas.ubc.ca/~mhasse/mce/bigphysarea-2.6.15.7.patch<br /> <br /> == Get kernel compilation packages ==<br /> <br /> apt-get update<br /> apt-get install kernel-package libncurses5-dev fakeroot wget bzip2<br /> <br /> == Make sure bash is your default shell ==<br /> <br /> sudo rm /bin/sh<br /> sudo ln -s /bin/bash /bin/sh<br /> <br /> == Uncompress and patch ==<br /> <br /> tar xjf linux-2.6.18.1.tar.bz2<br /> ln -s linux-2.6.18.1 linux<br /> cd /usr/src/linux<br /> <br /> bzip2 -dc /usr/src/patch-2.6.19-rc4.bz2 | patch -p1 --dry-run<br /> bzip2 -dc /usr/src/patch-2.6.19-rc4.bz2 | patch -p1 <br /> <br /> == Configure and compile ==<br /> <br /> cp /boot/config-`uname -r` ./.config<br /> make menuconfig<br /> <br /> make-kpkg clean<br /> sudo make-kpkg --initrd --append-to-version=-bigphys kernel_image kernel_headers<br /> <br /> (Can't use fakeroot in this last step, since the .deb are written to /usr/src.)<br /> <br /> == Binary kernel package installation ==<br /> <br /> See [[ MAS OS configuration ]].<br /> <br /> The .deb's that come out of the compilation above are incomplete, be we install them anyway. They are missing arch/i386/Makefile.cpu, and Modules.symvers. They might be missing other things too, but MAS really misses those ones. These have been put into a patch; which must be applied at the end.</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS_kernel_patch_compilation&diff=1586 MAS kernel patch compilation 2008-03-05T22:25:25Z

<p>Sysop: /* OS Installation */</p> <hr /> <div>E-mail templates:<br /> * [[ MAS OS Configuration email template ]]<br /> * [[ MAS PC specifications email template ]]<br /> <br /> <br /> == OS Installation ==<br /> <br /> - Boot from the 6.06 LTS server disk<br /> - Default install. Reformat boot partition. Make data partition!<br /> <br /> sudo apt-get update<br /> sudo apt-get install build-essential subversion emacs21 finger<br /> <br /> == Sources list ==<br /> <br /> - If you get trouble from apt-get because it can't/won't read the Ubuntu disk, or you don't have it anymore, like this:<br /> <br /> Media change: please insert the disc labeled<br /> 'Ubuntu-Server 6.06.1 _Dapper Drake_ - Release i386 (20060807.1)'<br /> <br /> then remove (comment) the line <br /> deb cdrom:[Ubuntu-Server 6.06.1 _Dapper Drake_ - Release i386 (20060807.1)]/ dapper main restricted<br /> from /etc/apt/sources.list and do<br /> apt-get sudo update<br /> <br /> <br /> == Kernel patch + compile ==<br /> <br /> - Get linux sources<br /> - Apply bigphys patch (don't add the -bigphys in the Makefile, do it in the make-kpkg!)<br /> - Follow the instructions here:<br /> http://www.howtoforge.com/kernel_compilation_ubuntu<br /> <br /> <br /> sudo rm /bin/sh<br /> sudo ln -s /bin/bash /bin/sh<br /> <br /> apt-get update<br /> apt-get install kernel-package libncurses5-dev fakeroot wget bzip2<br /> <br /> tar xjf linux-2.6.18.1.tar.bz2<br /> ln -s linux-2.6.18.1 linux<br /> cd /usr/src/linux<br /> <br /> bzip2 -dc /usr/src/patch-2.6.19-rc4.bz2 | patch -p1 --dry-run<br /> bzip2 -dc /usr/src/patch-2.6.19-rc4.bz2 | patch -p1 <br /> <br /> cp /boot/config-`uname -r` ./.config<br /> make menuconfig<br /> <br /> make-kpkg clean<br /> sudo make-kpkg --initrd --append-to-version=-bigphys kernel_image kernel_headers<br /> <br /> (Can't use fakeroot in this last step, since the .deb are written to /usr/src.)<br /> <br /> == Binary kernel package installation ==<br /> <br /> The .deb's that come out of the compilation above are incomplete, be we install them anyway. They are missing arch/i386/Makefile.cpu, and Modules.symvers. They might be missing other things too, but MAS really misses those ones. These have been put into a patch; which must be applied at the end.<br /> <br /> The steps are:<br /> <br /> # Install the kernel packages<br /> <br /> <br /> <br /> New boot options are: "bigphysarea=8192 acpi=off"<br /> <br /> Without acpi=off, loading the DSP driver will crash the system really badly. This has been observed in at least 2 machines.<br /> <br /> == After the new kernel ==<br /> <br /> For Ubuntu 6.06 LTS, add repository "Community maintained".</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS&diff=1585 MAS 2008-03-05T22:21:16Z

<p>Sysop: /* Installation / configuration */</p> <hr /> <div>* [[ MAS Overview ]]<br /> <br /> = Development =<br /> <br /> * [[ MAS Bug List ]]<br /> * [[ MAS to-do ]]<br /> * [[ MAS feature requests ]]<br /> <br /> = Installation / configuration =<br /> <br /> * [[ MAS PC requirements and initial setup ]]<br /> * [[ MAS OS configuration ]]<br /> * [[ MAS svn repository ]]<br /> * [[ MAS installation notes ]]<br /> <br /> = Usage =<br /> <br /> * [[ MAS start/stop ]]<br /> * [[ MAS Command line how-to ]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS_PC_requirements_and_initial_setup&diff=1584 MAS PC requirements and initial setup 2008-03-05T22:20:53Z

<p>Sysop: </p> <hr /> <div>E-mail templates for end users:<br /> <br /> * [[ MAS OS Configuration email template ]]<br /> * [[ MAS PC specifications email template ]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS&diff=1583 MAS 2008-03-05T22:20:32Z

<p>Sysop: /* Installation / configuration */</p> <hr /> <div>* [[ MAS Overview ]]<br /> <br /> = Development =<br /> <br /> * [[ MAS Bug List ]]<br /> * [[ MAS to-do ]]<br /> * [[ MAS feature requests ]]<br /> <br /> = Installation / configuration =<br /> <br /> * [[ MAS PC requirements and initial setup ]]<br /> * [[ MAS svn repository ]]<br /> * [[ MAS OS configuration ]]<br /> * [[ MAS installation notes ]]<br /> <br /> = Usage =<br /> <br /> * [[ MAS start/stop ]]<br /> * [[ MAS Command line how-to ]]</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS_kernel_patch_compilation&diff=1581 MAS kernel patch compilation 2008-03-05T22:19:40Z

<p>Sysop: MAS OS configuration moved to MAS kernel patch compilation: reorganization of installation documentation</p> <hr /> <div>E-mail templates:<br /> * [[ MAS OS Configuration email template ]]<br /> * [[ MAS PC specifications email template ]]<br /> <br /> <br /> == OS Installation ==<br /> <br /> - Boot from the 6.06 LTS server disk<br /> - Default install. Reformat boot partition. Make data partition!<br /> <br /> sudo apt-get update<br /> sudo apt-get install build-essential subversion emacs21<br /> <br /> == Sources list ==<br /> <br /> - If you get trouble from apt-get because it can't/won't read the Ubuntu disk, or you don't have it anymore, like this:<br /> <br /> Media change: please insert the disc labeled<br /> 'Ubuntu-Server 6.06.1 _Dapper Drake_ - Release i386 (20060807.1)'<br /> <br /> then remove (comment) the line <br /> deb cdrom:[Ubuntu-Server 6.06.1 _Dapper Drake_ - Release i386 (20060807.1)]/ dapper main restricted<br /> from /etc/apt/sources.list and do<br /> apt-get sudo update<br /> <br /> <br /> == Kernel patch + compile ==<br /> <br /> - Get linux sources<br /> - Apply bigphys patch (don't add the -bigphys in the Makefile, do it in the make-kpkg!)<br /> - Follow the instructions here:<br /> http://www.howtoforge.com/kernel_compilation_ubuntu<br /> <br /> <br /> sudo rm /bin/sh<br /> sudo ln -s /bin/bash /bin/sh<br /> <br /> apt-get update<br /> apt-get install kernel-package libncurses5-dev fakeroot wget bzip2<br /> <br /> tar xjf linux-2.6.18.1.tar.bz2<br /> ln -s linux-2.6.18.1 linux<br /> cd /usr/src/linux<br /> <br /> bzip2 -dc /usr/src/patch-2.6.19-rc4.bz2 | patch -p1 --dry-run<br /> bzip2 -dc /usr/src/patch-2.6.19-rc4.bz2 | patch -p1 <br /> <br /> cp /boot/config-`uname -r` ./.config<br /> make menuconfig<br /> <br /> make-kpkg clean<br /> sudo make-kpkg --initrd --append-to-version=-bigphys kernel_image kernel_headers<br /> <br /> (Can't use fakeroot in this last step, since the .deb are written to /usr/src.)<br /> <br /> == Binary kernel package installation ==<br /> <br /> The .deb's that come out of the compilation above are incomplete, be we install them anyway. They are missing arch/i386/Makefile.cpu, and Modules.symvers. They might be missing other things too, but MAS really misses those ones. These have been put into a patch; which must be applied at the end.<br /> <br /> The steps are:<br /> <br /> # Install the kernel packages<br /> <br /> <br /> <br /> New boot options are: "bigphysarea=8192 acpi=off"<br /> <br /> Without acpi=off, loading the DSP driver will crash the system really badly. This has been observed in at least 2 machines.<br /> <br /> == After the new kernel ==<br /> <br /> For Ubuntu 6.06 LTS, add repository "Community maintained".</div>

Sysop https://e-mode.phas.ubc.ca/mcewiki/index.php?title=MAS_OS_configuration&diff=1582 MAS OS configuration 2008-03-05T22:19:40Z

<p>Sysop: MAS OS configuration moved to MAS kernel patch compilation: reorganization of installation documentation</p> <hr /> <div>#REDIRECT [[MAS kernel patch compilation]]</div>

Sysop