Note that at the present time, there is always the single word "Error" at the top of the file. This has to do with initialization problems for the large screen display that we are not using, and can be ignored.
Note also, that there is not always error information in this log file, and I don't know why. I wish I did!
The template file is fairly well annotated with comments.
To make changes in this data, just edit the file. The next time you
invoke ALIA , it'll pick up this file by default.
It is sometimes important to understand what is written to the file
when, especially for file cleanup purposes after a workaround. Here is the
sequence of events:
ALIA output tp_nml file PD?:RRRRR_PPPP_NN.TP_NML
This file is not a straight copy of the template BIG.TP_NML file.
Instead, it contains only those namelists applicable to this scan; also some
namelists from the HW.NML file since that describes the scan; also some
bookkeeping information like scan duration; also, it does not contain any
comments.
If, for example, the shading, spot, and main rasters have had to be
performed with separate invocations, understanding this sequence of events will
help you figure out the file repairs that have to be done to produce a single
tp_nml file containing complete and accurate data.
ALIA output GSH file PD?:RRRRR_PPPP_NN.GSH
The ALIA program produces an extremely minimal GSH file, comparable to
that put on the optical disks, just before it begins each raster. This is
intended as a temporary file, used only by SPAM to allow the user to look at
the data. The real gsh file is produced by a separate program, run after the
scan completes. See the com file BASE:[CONTROL]RUN_HEADER_DB for a pointer as
to where to look.
Configuration files hwdev:[optical.gamma?]gamma?.config
Also known as "Gretchen's file of optical stuff", this file is automatically
copied onto the scan disk after the scan completes. It is an ascii file which
contains details of the current optical configuration of the machine.
To perform a scan with some other pixel size, do the following:
To generate the nonstandard task parameter file, copy ALIA_DATA:BIG.TP_NML to another location & filename, and then edit at will.
Invoke it by doing $run alia_exe:peek_at_alia_sections.dbg and then step about 10 lines. After you've connected to both sections, you can use the standard debugger tools to examine variables.
You can find relevant include files in ALIA:[INCLUDE] for the control section, and ALIA:[SAC.INCLUDE] for the console section.
Of particular interest may be the EH structure in the console section. EH stands for error handling. It shows the last reported message. Unfortunately this is in a numeric code so you need to search files like ALIA:[INCLUDE]ERROR_HANDLING.INC and ALIA:[INCLUDE]SERVO_ERRORS.INC to get any meaningful information out.
Invoke it by typing RUN ALIA_EXE:VIEW_CEFS.
Back to Table of Contents
Oh, right. If it has misfired then BASE won't be defined either. So look in DISK$SCHMIDT:[PLATEPROC.CONTROL]PIXEL1_BOOTME.COM.
Both sections are mapped to files located in PGS_PLACE, which is presently located in disk$data:[global_sections].
You can determine whether the permanent global sections exist by doing show dev/files pgs_place.
Additionally, a temporary global section is created by the controller to
hold the data buffers for each scan. This section is called, logically enough,
the DATA_SECTION. It is accessed by the data collector, laser monitor, and data
processor. The file that it is mapped to also is in pgs_place.
Back to Table of Contents
Then, when it gets to the routine SPAWN_OTHER_PROCESSES, it will ask you whether or not to run each of the other processes. If you say YES (the default), it will spawn & run the non-debug version of that program. If you say NO, you must then go to another window and manually run the debug version of that program, eg, RUN ALIA_EXE:LASER_DATA_PROCESSOR.DBG .
Thus if you want debug access to all 7 programs, you'll need 7 windows.
Generally you won't need this. I generally have run with only 1 or 2 other
programs in debug mode.
To debug the SAC , instead of using the start_sac command, do run alia_exe:stand_alone_console.dbg . This will run the SAC interactively, still attached to the DECterm you start it from. This is a useful technique when the SAC keeps dying without leaving any clues to what it is doing.
Back to Table of Contents
For example, the following describes the approach I used to diagnose a byte count error that turned out to be a problem with the scaler.
First, I ran the servo process in debug, and set breaks in the
reset_steady_state routines so that I could examine what the marker (XMKR)
commands were that were being sent to the servo. Then, while the program was
still paused, I used IDL to query the servo and register that those numbers
had indeed been received. This seemed to exonerate the servo itself. It also
changed the symptoms a bit, presumably since the timing of things was changed.
The new symptom was that the empty light did go off, but the FIFO filled up,
ie, no internal reads were being performed. As it happens,
I then ran the data_collector in debug, and set traces at the LAST_PIXEL_AST, FIRST_PIXEL_AST, and SPIT_OUT_FIRST_WORD routines, and ran without breakpoints. This verified that, indeed, the first pixel ast was not going off until the end of the pass. (The spit_out_first_word routine never got called; the last_pixel_ast went off nearly as soon as it was set; and the first_pixel_ast went off near the end of the pass.)
This looked to me as if the count of pixels in the scaler was off somehow, so I tried pressing the reset button before starting the next raster, and indeed, this cured the problem.
Back to Table of Contents
This procedure sets
Back to Table of Contents
This procedure sets
To rebuild ALIA with your "tweaked" changes, set default to hwdev:[supertasks.alia] and do mms/skip/descrip=alia:[mms]alia.new_descrip . This will recompile any code that has been changed, and relink everything. It does take quite a while. If you know you only need to rebuild one program, you may give it that program as an argument, eg, mms/skip/descrip=alia:[mms]alia.new_descrip data_collector.exe, data_collector.dbg.
Note that map files will go into alia:[map] , exes will go into alia_exe , and object and list files will go into disk$hw:[scratch] . You may need to purge these areas periodically to keep from running out of disk space.
Back to Table of Contents
Back to Overview
Vicki Laidler -- laidler@stsci.edu
Last updated 12/17/96