Many engineering commands take an argument describing a target ``board'' or endpoint inside the controller. For SDSU systems, this argument is typically either:
If multiple controllers are connected, the command will apply to all of them unless a 0 or M is applied for the first (or master) controller, a 1 or S for the slave or second controller, or 2 and so on if a system as more than two controllers. To apply a command to the slave utility board, the argument
lubS
can be used. To apply a command to all boards in the master controller, an argument of just
M
is also possible. This syntax is used where-ever the help screen specifies ``LB''.
``Test Data Link'' is the first test to use in determining if the controller is connected. While this is an engineering command, it is also available in observing mode because it is harmless. Many other commands include a quick ``tdl'' check at the beginning just to verify that things are connected. Since all known boot proms in existing timing boards and utility boards support TDL, for SDSU, this command is always available, even if specific DSP code has not yet been loaded and booted in the controller.
By default, tdl checks all boards with several data patterns. The first argument can be used to single out a specific board, and an optional third argument can be used to specify a data pattern to write.
This command is also known as download. It loads the last known DSP code files to the controller and begins execution of the code. In engineering mode, this command also takes optional arguments to specify a board, and a filename of a ``.lod'' file to load. In observing mode, this is disabled for obvious reasons, and boot can only be used by itself to retry booting the already selected code. If boot is able to determine that the code is already loaded, it returns immediately. As with tdl, many higher level commands contain a quick call to boot to make sure all DSP code is loaded before proceeding, so the observer typically never uses this command.
This command can be used to read the current value of a DSP code symbol. The symbol names used here can also be used as address arguments to the commands below, instead of specifying the numeric value. This mode of addressing memory locations in the DSP is much safer than using the actual address, since the addresses could change or shift if the DSP code is modified.
This takes two arguments. An LB specification as described at the top of this section, followed by an address argument. The address argument can either be a DSP memory location specified as MEMORYSPACE:HEXADECIMAL_ADDRESS, or the name of a symbol, like OPTIONS.
As an example, to read the OPTIONS bits of all endpoints in all controllers:
rdmem * OPTIONS
Since the rdmem command is harmless, it is enabled but not advertised in observing mode.
Like rdmem, the first two arguments to this command are the endpoint and the address. A third argument must be specified giving the new value to be written to the specified memory location. This argument can either be a numeric value, or the name of an ``N:'' symbol in the DSP code. ``N:'' symbols in the DSP code can also be used as offsets, and when combined with a fourth argument to wrmem, this command can be used to turn on or off specific bits at a memory location. The special keywords ON and OFF have been defined as ``all bits on'' and ``all bits off'' to facilitate this. An example illustrates best:
wrmem ltb OPTIONS ON 1<<CUSTOMOPT
would turn on a CUSTOMOPT bit (CUSTOMOPT would be an ``N:'' symbol with a value of 0..23) in the OPTIONS of all timing boards.
DetCom uses this method internally to manipulate the options bits it knows about (test-pattern, disable shutter for darks, calibration LEDs) so that other bits are left as the user set them.
Because of potential risk to the detectors, use of this command is disabled in observing mode.
Normally, DetCom saves data at the same time a go is issued. If all data could not be saved successfully, another attempt to save the last-read data to disk can be made by typing save. DetCom does not currently check that there is enough disk space to save the next readout before starting the exposure, so the save command can be useful when a disk fills up. The exposure is not lost until a new ``go'' command is issued. This command is not advertised to users, but it is also available in observing mode.
This engineering command can be used to disable writing of a FITS file during a readout. If this mode is enabled during testing, a single frame (the last one read from the camera) can still be saved to disk by typing save manually.
This engineering command enables/disables the ``sweeping'' mode which cleans the detector constantly during idle time.
This engineering command enables/disables testing of the detector voltages during idle time. Voltages are displayed to the user in the ``info'' bars below director's shell prompt. These same lines are used to display file-saving progress during a readout.
This engineering command (not available to observers) can be used to send any arbitrary three-letter SDSU command to any endpoint in the controller. The first argument is the board specification. The second argument is the three letter command, and an optional fourth argument specifies the expected response (use this if the command returns something other than ``DON''.) An optional fifth argument specifies the maximum time in milliseconds to wait for a response. (The default is 3000 milliseconds.) For example, DetCom uses this command internally to clean the detectors:
cmd ltbS CLN cmd ltbM CLR DON 8000
(Of course the user just types clean, but this is what happens inside.) To send a command which expects no response at all, use '' (the empty argument) for the their parameter:
cmd ltb RDC ''
(This usage is very rarely needed.)