|
|
|
Wide Field Infrared Camera (WIRC) Software User Manual
View the original user manual.
The present manual gives a brief idea of the system and its main components. The topics covered here are:
- Basic components of the system
- Starting and shutting down the system
- Main GUI
- Filter GUI
- TCS GUI
- ROI GUI
- Scripting
- Custom scripts: focus, snap, wcenter, wcal
- Appendixes
Contents
1. Basic Components of the System
The ArcVIEW software allows the user to interact with the detector controller for taking images, as well as with the TCS for making offsets or focus changes, and with the filter wheel for changing filters.
1.a. Software Architecture
The system works on a client-server scheme. There is a server, which receives requests from the connected clients to execute actions, like sending a command, etc. After the action has been executed, the server sends back to the client the response or any error condition.
For the WIRC software, the client, which requests actions, is the main GUI itself. When the main GUI is opened, it connects to the server (which is already running on the machine).
The connection between the server and the clients is done using sockets (TCP/IP), which means that the client (the GUI in this case) doesn't need to be on the same computer that the server does. This means that the actual GUI can be, moved away from the WIRC machine without any change.
Server
The server loads and calls specific modules for performing any requested command. This means that the actual action is performed for some specific module. This module is the only module which will need to know the internals of the process or the systems that it is handling. For example, if some controller command arrives (i.e. EXPOSE), the server will call to the specific SDSU-II module. This module knows how to send the command to the controller (only it knows about the Linux driver and the C library for communicating with the specific hardware). After the action has been done, the server receives the response from the module and repeats it back to the client. This modularity allows the software to be independent on any specific hardware. If a different controller than the SDSU-II needs to be controlled, it is just a matter of adding a new specific module for that hardware without affecting any other part of the system. The same applies for the TCS, filter wheel, etc. For a list of all the available modules, see the Software Tree.
Client
As mentioned before, in the WIRC case the client is the main GUI itself.
All of the buttons in this GUI are being transformed into ascii commands (like
TCS FOCUS 40).
The GUI system is composed of a main GUI, and several plug-ins. The plug-ins are dynamically loaded GUIs which extend the basic functionality of the main GUI. This allows the user to open only the functions desired; all the other functions can be avoided. For example, from an engineering point of view, there are a lot of low-level commands which are quite useful (commands which are not interesting for the normal observer). For that specific purpose there is a special plug-in (a special GUI) which can be loaded for adding this extra functionality. The plug-ins are basically GUIs opened on demand around the main GUI for performing specific sets of commands.
In this specific application, besides the main camera GUI (which takes care of the basic imaging issues and detector communication), we have the following plug-ins available:
- PI_WircFilterGUI : takes care of all the filter-related commands and status.
- PI_TCSP200GUI: takes care of all the TCS-related commands and status. This GUI will send all the commands and receive all the responses to and from the TCS.
- PI_ScriptServer: This PI allows the user to handle the whole system using external scripts (under IRAF, csh, TCL or any other scripting language).
- PI_ROI : Allows the selection of a Region of Interest (array subwindow) to be read.
Apart from these, and only for engineering, we have:
- PI_Labmain: opens a GUI specialized on low-level commands (like setting DACs, reading or writing DSP memory locations, etc).
- PI_voltages: allows user to read back and log the values of the power supplies of the controller.
- PI_ViewLogs: allows user to see, in real time, all the logs that the system is generating (command/responses, errors, information, messages, etc).
1.b. Virtual Network Computing (VNC)
The Virtual Network Computing (VNC) is basically a Windows Manager (like KDE or GNOME) that can be accessed through the net. This VNC Windows manager (VNC server) accepts connections from multiple clients through the network. Every client connected can see and, if allowed, act over the server. This means that every client can see exactly what other client is doing inside the VNC server.
This is quite useful because it allows to have remote access to anything which is happening inside the server.
VNC is being used on the WIRC machine. All the ArcVIEW applications are being started inside a VNC server; therefore, all of what is happening can be watched remotely using a VNC client.
Information on how to connect to the servers remotely is on the Starting the System section.
1.c. Network Time Protocol (NTP)
The Network Time Protocol is used on the WIRC instrument machine for synchronizing the Local Clock with Palomar's GPS server clock. This synchronization gives a typical error of less than 30 msecs, which means that the times indicated on the image headers (UT, for example) are within this range of error.
The NTP server starts automatically when the machine boots.
The NTP configuration file is on /etc, and it is called ntp.conf. More
ntp files are in /etc/ntp.
More information about this protocol can be found in ntp.org.
2. How To Start and Shut Down the System
2.a. Starting the System
Start VNC Session
From the observer workstation, click the VNC icon for the instrument computer that WIRC is using
(usually INSTRUMENT_6). You will be prompted to enter the password. Once the password is entered,
the desktop for the instrument computer will open.
Open the GUIs
Start the main GUI by clicking the WIRC icon on the instrument computer's desktop.
A green dialog box will open and show the startup progress. The main GUI, filter GUI,
and TCS GUI will then open.
Open the dithering tool by selecting DITHERING from the
special functions dropdown
menu in the TCS GUI. On the Dithering GUI, click the show button
to open the dither graph.
Open IRAF Window
Click the irafred WIRC icon on the VNC desktop background. At the
cl prompt,
type cd /rdata/WIRC/<date> to change to the current data directory.
Type wirc to open the wirc task package.
Open Real Time Display
Click the DS9 real tim WIRC icon on the VNC desktop background to open the
real time display window.
Open Full IRAF Session
On the workstation's right monitor, click the wirc iraf icon to open a DS9 display
and full IRAF session. At the cl prompt, type cd <date> to change to
the current data directory. Type wirc to open the wirc task package.
2.b. Shutting Down the System
For shutting down everything, press the QUIT button on the main GUI. You will be asked to confirm the operation. Press yes all the GUI windows will close.
3. Main GUI
3.a. Main Interface
This is the main user interface. It allows the user to take images, enter header and exposure information, and receive status information.
Main GUI.
3.a.i. Middle Section: Inputs
The middle section of the GUI is where the user inputs all needed information.
Basename: Root name used for composing the name of the
image. For example, object will generate images named objectNN
where NN is
the sequence number. If an image with that number already exists in the directory,
the old image WILL NOT be overwritten; the new image will be renamed
basenameNN_i, where i=0 ... 20. After 20 consecutive images with the same
name (after basenameNN_20) an error will be returned.
Sequence Number: This is the number that will be combined with the basename to give the image name. It automatically increments as exposures are taken.
Title: This name will appear as the OBJECT keyword of the fits header,
and this name will appear, for example, when doing a imhead <basenameMM>
under IRAF.
Path: The data directory is created when the software is started, and the path is automatically set. DO NOT edit the path field; it can crash the GUI. If there is a problem with the path, consult the support astronomer.
Comment: Any additional information desired. This will
appear on the image headers as a COMMENT keyword.
ExpTime: Time, in seconds, that the detector will
be exposed to photons. This number is the TOTAL exposure time, which means
that the read time is included. The minimum exposure time is, therefore,
the readout time, currently aprox 3.5 seconds. If the user types in 10,
then the detector will be in a "idle" state (not clocking) only 6.5 seconds,
and the remaining time will be the readout time.
NOTE: the best linearity is between 3,000 ADU and 36,000 ADU.
Fowler: Number of fowler samples to take (number of times the detector will be reset prior to the exposure and will be read after the exposure).
Coadds: Number of coadds performed in memory before writing the image to disk. There is no limit in this number.
Repeats: number of sequences to take. Every "sequence" will result in an image, even when this image can be itself the result of several reset-expose-read sequences coadded. See algorithm scheme above.
Observer: name of the observer. This will appear on the
fits header as a the value of the OBSERVER keyword.
write automatically: If checked, the image will be written to disk automatically after being read and preprocessed. If not checked, a button called write will appear when the image is ready for being written, so the user can examine the image and write it only if desired.
display automatically: If checked, the image will be displayed, when ready, automatically on the image displayer (Ximtool or DS9) if this is opened.
All this is "static" information, in the sense that cannot be changed while the actual image is in progress.
3.a.ii. Lower Area: Control Buttons
The lower part of the GUI allows to control the behavior of the GUI when taking the exposures (dynamically).
GO EXPOSURE: initiates everything.
ABORT: abort all activity immediately (whatever status the system is) and return to the idle state. Current image will be lost.
Stop seq: will wait until the current image is taken, and then stop gracefully.
Stop coadd: will wait until the current coadd finish, and then will stop gracefully.
The "looping" algorithm is:
DO sequence TIMES {
IF (STOP sequence)
EXIT
DO coadd TIMES {
IF (STOP coadd)
EXIT
DO fowler TIMES
reset
expose
DO fowler TIMES
read
subtract (exposed frame - reset frame)
unscramble, write to disk
display (if selected)
}
}QUIT: This button will close the GUI, causing the disconnection to the controller, the filter wheel and the TCS (if connected). A confirmation will be required.
Select a PlugIn: This is a drop-down menu which allows to open any available plug-ins.
3.a.iii. Upper Area: Status
All the status returned is in the upper part of the GUI. The status is:
System Connected light: When "on" indicates that the client is connected with the Server (basically, the GUI is connected to the Software which actually handles the system).
Controller Ready light: When "on" indicates that the controller was successfully initialized and that it is ready for receiving commands.
If this two lights are "on" means that the system is totally ready. All this initialization process should take about 2-3 seconds.
Left side: all the controller-related issues (reset, read, expose):
Controller State: upper part: messages related to the status of the controller (like current task, information, etc.)
Detector State: state of the detector; this can be:
- idle (doing nothing but in continuos reset mode)
- resetting (in a reset cycle, clocking out the reset frame, prior to expose)
- exposing (exposed to photons with no clocking)
- reading (in a read cycle, clocking out the array the exposed frame)
Exposure Progress: exposure time progress, in seconds, from minimum exp. time (readout time) to requested exposure time.
Readout Progress: percentage of the frame read so far. This bar will change with either the reset or the read cycles (in both cases we are reading out the array).
Write Progress: progress of the process of writing the image to disk.
Right Side: all the host-related issues (like image on disk, etc.):
Image State: what is the status of the writing or preprocessing of the image on the host (like making the coadding, waiting for the next frame to finish or writing the image).
Path: actual path to the image being processed (normally the same specified for the user).
Name: actual name of the images being written (normally the same specified for the user).
disk usage: usage of the current disk (filesystem). It will turn red and return an error when the disk space remaining is not enough for holding the requested images.
Host: name or IP address of the machine in which the images are being written.
3.b. System Setup
The button located on the lower area of the GUI called GUI SETUP
will open a window different tabs, which will handle specific aspect of
the configuration of the Main GUI. This configuration includes paths to
log files, general information, choices for error handling, etc.
All this information is stored in a configuration file called ctiocameragui.cfg,
located in the general area for
the configuration files ArcVIEW/ConfigFiles/. In this file,
there is one entry per tab. We will see here the more important points on the setup,
which are:
3.b.i. Initialization Tab
The Initialization tab has the most important configuration: all the initialization and startup conditions.
Startup Config: This describes the path to the startup configuration file, which describes how to setup the controller when it boots. This is an ascii file which holds information like the type of detector, the geometry, the size of the detector, the sequence of commands to execute automatically when it starts (like "power on", "set display image", etc.), which DSP files to load on the controller, etc. This file is already set, and it SHOULD NOT be modified by the normal user.
Available plug-ins: Here you can control which plug-in you want to be started automatically. Just select the one you want and press the > button to copy it to the start automatically box. When you close the setup window USING OK, all you changes will be saved to the configuration file. The next time you start the system the selected plug-ins will start automatically.
3.b.ii. Information:
Here you will find interesting information related to the controller configuration, read directly from the SDSU-II DSP (things like the installed cards, versions, detector, etc.).
4. Filter Plug-In
Filter GUI.
This plug-in handles the commands and status of the WIRC filter wheel. This plug-in is normally started automatically when the system starts. This is, however, configurable. Basically, with this GUI the user can select which filter to use, as well as initialize the filter wheel. The user (or normally the operator) can setup too the order of the filter wheel according to the actual physical order on the wheels. When you open the plug-in, the first thing that it will do is to ask the motor controller box for its status and the wheel positions. If it fails to get such information, it will get an error message, meaning that the motor controller needs to be initialized. We preferred to leave the choice of initializing the motor controller to the user.
For having an idea on the actual physical mechanism for communicating with the motor controller box, please refer to the motor controller diagram.
Configuration Files:
ArcVIEW/ConfigFiles/filtersgui.cfg → general filter GUI configuration
file
ArcVIEW/ConfigFiles/filters.list → filter list
The filter list file is an ascii file describing the names, IDs, focus, position and color code representation for each installed filter. The layout of the file is:
[wheel 1 name] filtername1="ID1 position focus colorcode" filtername2 = ... .. [wheel 2 name] . .
This is the file read when for displaying the filter names and defining the positions on the GUI. The operator who install the filters can edit this file manually or can do it graphically using the filter editing tool.
4.a. Middle Area
FILTER LIST: here the user can select which filter list you want to go next. It is a drop-down menu which has all the filters available.
Move: Causes the filter wheel to actually move to the above indicated position.
independent wheel control: if checked, the FILTER LIST control will transform on two drop-down menus, one for each filter wheel (FORE and AFT). In this way the user can move independently every wheel. This gives more flexibility to the user, but it is potentially dangerous, in the sense that the user can finish with a useless configuration (two filters) and there is nothing to prevent this in this mode.
Important Note: The NOT independent filter wheel control (which
is the recommended way of using the system) is really hiding to which position
the wheel which does not have the selected filter will be sent. This is
normally OPEN position (for example, if feII is selected, AFT will be sent
to feII and FORE to OPEN ... this is just an example ....); however, in
the configuration file above mentioned there is a couple of keywords which
indicates the position to which the wheel will be sent automatically (foreopen
and aftopen). In other words, if independent wheel control is
NOT selected, the wheels will be driven in this way:
if (selected_filter |E AFT)
MOVE AFT selected_filter FORE foreopen
else
MOVE AFT aftopen FORE selected_filter
where |E means "belongs too", and foreopen and aftopen
are the filters specified in the configuration
file (normally "OPEN") for FORE and AFT wheels respectively.
log: check if you want to log all the transactions. You
need to specify the log file name and dir (normally ArcVIEW/Logs).
show wheels: shows a picture of both filter wheel and the current positions. Each filter is represented with a different color. The picture is updated on "real time."
get filters: get the filter names. This should be used only if, for some reason, no names appears on the filters drop-down menu.
4.b. Lower Area
Motor init: Initializes both filter wheels. This action needs to be performed at least the first time you turn on the motor controller box. When you open the plug-in, it will try to communicate with the motor controller box. If it fails, it will write the error messages in the status area. When you press this button it performs the following actions:
- Configure the serial line;
- Configure the two motor controller cards on the remote (Primary focus) motor controller box (PIC-STEP);
- Send both wheel to the home position. After each position has found its home switch, it is sent automatically to the first valid position.
If for some reason you need to turn off the software, or close the PI, the next time you open it it will again try to communicate with the motor control box; if it was previously initialized it will receive the right status and it will not be necessary to reinitialize.
QUIT: quits the PI.
4.c. Upper Area
This is the Status area.
motor light: It will turn on when the filter wheels are initialized and ready for receive commands.
error light: it will turn on when any error occurred when performing a command (communications or reported by the motor controller box).
Timeout light: it will turn on when there was no response from the motor controller box, normally meaning an error on the communications line.
Command: this are will show the actual serial command sent to the motor controller box.
Cmd Status: status of the command sent (like waiting response, or OK, etc.).
Response: actual response got from the motor controller box.
Motor Status: status of the motor controller box according to the last response to the "status" command (sent automatically) or to the last issued command. This will be like moving, etc.
5. TCS GUI
This plug-in takes care on the communications with the P200 Telescope Control System. When it is opened, it sends a request to the Server software to connect to the TCS.
After it is connected, it will send the requested commands and will print the received responses and information.
5.a. Lower Part: Commands
TCSP200 GUI.
In this area the main commands (offset, focus and Zero) can be entered.
Command: shows the command which is in progress. This area will blink when any command is in progress.
Response: here the response from the TCS will be shown. This includes any error message.
log: checking this box will cause the plug-in to log all the transactions.
timeout: this control says the amount of time to wait
for a response to complete. if -1, means that the timeout applied is
the default value, which is 90 secs.
focus: the user can enter the requested focus value in the control box. By pressing the focus button the specified value will be sent to the TCS in a relative sense. These will be focus bumps not absolute moves. The green bar on the low can be used for entering the absolute value in a graphic way.
offset: by pressing this button the values of RA and DEC on the correspondent boxes will be sent to the TCS. The values are in arcseconds with East and North Positive, and West and South negative.
more commands >>: by pressing this button the window will expand, and will let the user send ANY available command to the TCS using a set of drop-down menus and a control for sending the string commands. This is normally not required, and for that reason is not being shown here.
5.b. Upper Area: Status
TCS light: this light will be on when the connection to the TCS is up.
Timeout: will turn on when a timeut occurred for the last command sent.
Error: will turn on when any error occurred sending the command.
UT, focus, Coords: will normally show the current focus value, offset and UT time. This controls may be disabled for local observing.
commands >>: Pressing this button will have opposite reactions, depending on the state of the plug-in. If it is on the same state than the picture shown, then it will cause the lower part to collapse, leaving only the upper part (only the status). If only the status is shown, then pressing this button will cause the window to expand and the lower part to appear. This is basically for saving screen space if not tcs commands are being sent manually.
5.c. Special Tools
This is a drop-down menu which will show all the specialized functions available. These functions are more specific TCS tasks which will be better performed in an automatic way.
5.c.i. Dithering Tool
By selecting DITHERING on the drop-down menu, new window will be opened.
The dithering tool will allow to the user to perform automatically a series of objects by basically performing a set of offset-image pairs. The white area indicates the series of offset desired. The tool will go to the first line, it will perform the offset to the telescope, and then it will take an image, according to all the parameters specified on the Camera GUI.
Basically, what the tool does is to manipulate both the TCS plug-in and the Camera GUI by filling the controls and pressing the buttons, in exactly the same way that a human user would do , but automatically and much more efficiently.
Dithering tool.
The upper display (which says READY on the picture) indicates the status of the task (performing offset, or taking image, etc.).
offsets: shows the array of offsets to perform. This list can be directly edited on the tool by pressing the Edit button, or can be loaded from a file.
Offset Type: indicates the type of offsets in the array. This can be of two different classes:
- Relative: indicates that every offset is relative to the PREVIOUS offset, so every offset is relative to the previous position.
- Absolute: indicates that every offset is relative to the STARTING position, so every offset describes an absolute position if you are standing on the starting point.
return to orig. position: if checked, the telescope will be sent to the starting point when all the list of objects has finished.
Repeats: number of times you want to repeat the whole list.
The algorithm is as follows:
DO Repeats TIMES
WHILE Offsets NotFinished
DO OFFSET
DO IMAGING
Next on Offsets List
The tool will indicate the current object by changing the correspondent line to blue. The blue line will then keep moving line by line until the end of the list.
show: will show a graphical representation of the offsets to perform. It will show the current position (blinking), the positions already done (green points) the positions to be done (white) and the positions in which any error occurred (red)
load: you will be prompted for the location of the file to load. The file must be an ascii file with two columns per line. The first number will be interpreted as the RA position, and the second as the DEC position. Any following character on that line will be ignored. Any line starting with something different than a number will be skipped (so comments are allowed). A sample file would be:
#Dithering file #RA DEC 10 20 This comment will be ignored -10 -20 +20 0 this line will be skipped 0 0
save: you will be prompted for the name and location of the file to create. The current list on Offsets will be saved to the indicated file as an ascii file.
Edit: pressing this button will open a new window in which you can edit the current list. You can insert/delete rows, modify values, etc. If you do this while the tool is running, your changes will take effect immediately after you accept the changes; this means that you don't need necessary to STOP the dithering for making changes.
STOP: will cause to stop the dithering list. This means that it will finish the current object (offset/image) and then will stop before executing the next one. It then will NOT abort any current action.
GO: Will cause the action to start. The dithering will start from the place where the blue line is. As you can choose manually the position of the blue line by simply clicking on the desired position, you can start the dithering from any place. This means that, whether you are resuming a previously stopped dithering or you are starting a new one, this buttons behaves always the same. It just start the action from the place where the blue line is (so it would be "resume" and/or "start")
quit: will close the tool. It this button is pressed when the tool is actually performing a dithering, it will have the same behavior the the STOP button: it will wait until the current object is finished (offset/image) and then it will quit before starting the next one in the list. There is no way, then, of aborting actions from here.
6. Region of Interest Plug-In
With this GUI is possible to select a subwindow of the array to be read. It is possble to select just 1 subwindow, square and centered. The subwindow size must be a multiple of 256. Values goes from a 2048×2048 (full array size) to 256×256 (minimum size).
Region of Interest plug-in.
The white area on the left shows basic info on the array.
The square labeled as "Region of Interest" shows the selected size to be
read. All coordinates are refred to the lower left corner, which has coordinate
(1,1).
xstart: starting column
xsize: amount of columns
ystart: starting row
ysize: amount of rows
The selected ROI would be then
[xstart:xstart+xsize,ystart:ystart+ysize].
Note that this is an indicator only. The actual control is the slide bar on the bottom. You can handle the bar or the yellow digital indicator directly. Here you define the size.
The ReadTime indicator shows the estimated readout time for the ROI selected. This value depends on the pixel read time as well as the time for skipping the undesired area.
7. Scripting
ArcVIEW can be handled almost completely by external clients which connects to it. In this case, we will describe how the system can be handles using any type of external scripting or programming language.
There is an important plug-in called PI_ScriptServer. This plug-in is an interface between the internal ArcVIEW (Client-Server) protocol and any external ascii-based strings. Even when all the messages inside ArcVIEW are ascii ones, there are some protocol mechanism involved (callbacks, etc.), so the script server translates basic ascii command into ArcVIEW messages.
The Script Server has two ways of communicating with the external world:
Sockets: These are the most used. The ScriptServer is listening in a socket (currently is a fixed port: 1314). Files: In the event that a user can use file-based mechanism instead of socket, it can be done. The ScriptServer will receive the command from a file, and will give the answer on another file. This is the simplest way of handling it, since does not involve using socket or any special protocol.
The ScriptServer will receive any command , it is going to send that command to the Server, and it is going to send the response to the caller. If a "callback" mechanism is involved, there is two ways of handling it: in block or unblock mode. In block mode, the ScriptServer will not send any response until the Callback message has arrived. In unblocked, it will send the "OK" immediately after the firs "immediate" response was received from the Server.
Examples of Cshell scripts can be found on ArcVIEW/PlugIns/ScriptServer/demos/Csh.
Here are examples for taking images using Csh scripts through both a file and a socket.
7.a. WIRC Scripts
As already mentioned, you can use any scripting language that you want
for handling the system (Csh, CL, TCL, Python, etc.). However, most of the
WIRC scripts that are already done and available
for handling the system are are written using CL, which is the IRAF scripting
language.
All this scripts for handling the system are under the wirc iraf package,
that it is located on
/home/wirc/irafpkgs/wircpkg/.
For accessing these scripts, the user just needs to type wirc on any IRAF
(cl) console and the wirc package will be loaded, leaving all this script
available for usage. The basic scripts are done. If the user wants to build new ones, s/he
can use this basic ones as "bricks" for building more complex ones.
For editing the parameters of any CL script, you need to type epar
taskname, and that will take you to a screen for editing all the parameter
of the script.
Important NOTE: In order the scripts which communicates with the ArcVIEW system to work, the plug-in PI_ScriptServer must be running. You can select it to start automatically every time the system starts, or you can start it manually.
Basic-functionallity scripts
observe: Script for taking images. This script will prompt for the basename, the starting image number, the exposure time and the amount of images to take. Depending on the parameters on the enable file it can prompt you for telescope offset, telescope focus and/or filter wheel position (so it can perform all this actions).teloffset: this script will move the telescope on the specified offset (will ask for RA and DEC values).telfocus: script for changing the telescope focus (will ask for focus value).filter: script for moving the filter wheel. It will ask you for a position. You can control the filters independently or both at the same time depending on the setting parameters. The installed filters must be described on thefilterparsfile.motorinit: initializes the filter wheels.
More elaborated scripts
dithering: this script allows the user to take a sequence of dither frames, loading a sequence of objects from file. This script will call (internally) theobservescript for taking the images and theteloffsetone for moving the telescope. The offsets must always be related to the starting position. According to a parameter, the telescope can be moved to the initial position at the end of the object sequence. Some example dither files can be found on/home/wirc/irafpkgs/wirckpkg/*.dat
Parameter files
The parameter files are files for setting up general
functionality. This files are edited on the cl window itself, by just typing
its name as a normal task. The files currently used are:
enable: this file says if the
observe
script will, besides taking the image, move the telescope and/or change
the telescope focus and/or move the filter wheel.
obspars: This file sets some parameters
specific to the observe script (like auto numbering).
filterpars: here must be defined
the positions and names of the filter wheels, so the filter script
knows which position for each filter is requested when the user ask for a
filter name.
telpars: set some parameters specific to all the telescope
scripts (teloffset, telfocus).
How to build new Iraf scripts
For adding more Iraf scripts, the steps to perform are:
- Create the actual CL code: this can be done taking as examples some of
the alreday-done ones. You can call any already-defined script from inside
your new script. Look into the
dither.clscript (this script is callingobserveandteloffset) orobserve.cl(this is callingteloffset,telfocusandfilter) as examples. - After you have your new code, you must edit the file called
wirc.cl, and add your script there, so when the wirc package is loaded it will leave your new script available for execution. What you need to add to the list is:
task taskname = wirc$taskfilename, where
taskname is the name that appears as your script "procedure" name, and
taskfilename
is the name of your file (normally taskname.cl).
After that, you need to reload the wirc package by typing bye and then
wirc, or unlearn wirc, and then wirc.
We must note that already exists a "custom WIRC package tool", mainly provided by Dave Thomson. The package is called WIRCtools and it is available for any user. This is the place intended for observers and users to contribute with public scripts.
7.b. Special Script: BurnDVD
This Iraf script allows the user to burn a DVD-R, DVD-RW, CD-R or CD-RW with data. The wirc package must be loaded for the script to be available. The required parameters are:
cl> wirc
wi> epar burn
PACKAGE = wirc
TASK = burnDVD
sdir = /home2/wirc/images) source dir
(vlabel = ) volume label (defaults to current date)
(capacit = 4489) disk capacity (MB) (1MB=1024x1024K)
(isodir = /home2/wirc/dvdfiles) directory for temporary iso files
(isofile = iso.raw) temporary iso file name
(type = DVD-R) device type
(deletei = yes) delete temporary iso file at the end?
(reuse = no) reuse existing ISO file?
(dummymo = no) try dummy mode first?
(verify = yes) verify data written correctly to dvd?
(devdvddir = /dev/dvd) device directory
(mntdvddir = /mnt/dvd) mounted device directory
(mode = ql)
sdir: source directory, which contents that data to be burned.
vlabel: desired label for the volume. It will default to
the current date.
This two parameters will be asked every time you run the script. The remaining ones are "hiding", which means that the user must change its "manually" (they will not be prompted).
capacity: capacity of the media to be used, in MB.
As a reference, a standard CD-R and DC-RW has 650-700 MB, while a standard
DVD has 4489 MB (4.7 GB).
isodir: directory for storing the temporary ISO file that
needs to be created for writing the media.
isofile: name that the ISO file will have. If a file already
exists, IT WILL BE OVERRIDDEN.
type: type of device to use. Choices are DVD-R (recordable
DVD, for writing once, of type -R), DVD-RAM, CD-R (recordable, for writing
once), and CD-RW (re-writables CDs). Note that DVD+R or DVD-RW will
not work.
deleteiso: controls if you want to delete the ISO file once
it has been written to the storage media or you want to leave it on disk.
reuse: controls if you want to create a new ISO file from
the source dir to burn the media, or if you already have an ISO file and you
want to use it.
dummymode: controls if you want a real burn or a dummy burn.
Dummy burn are useful if you are not sure the media you have is compatible
or if it is going to work. The dummy mode performs all the steps that the
real burn will do, but the actual laser is turned off during the burning
process.
verify: if YES, runs an md5checksum on data in source directory
and compares to md5checksum on data written to the dvd. Errors, if any, are
then listed.
devdvddir: path to the dvd device (/dev/dvd on WIRC2 computer,
/dev/dvdram on WIRC computer).
mntdvddir: path to the mounted dvd device (/mnt/dvd on WIRC2 computer,
/mnt/dvdram on WIRC computer).
mode: internal use.
This script uses the mkisofs program for generating the ISO
file, and the cdrecord-proDVD one for the actual burn. The
script is very simple, and it is going to performs the following steps:
- verify that your writable media has enough space for storing your source dir;
- verify that there is enough space available on for storing the temporary ISO file (on the specified filesystem);
- generate the ISO file if requested;
- burn the media on the requested mode (dummy or real).
7.c. Demo Scripts: Image Puller
These are part of the arcview package. They get images from a remote host running an ArcVIEW database module (DBS).
Main script: getimages.cl
Called scripts:
getimlist.clpullimages.clerasefromlist.clpostproc.cl
How it works:
For general information about how the images are pulled from the remote machine, see the Data Reduction Computer documentation.
getimages will be forever on a loop asking the remote dbs from an image list
(through the getimagelist task). Everytime an image list is got, it passes
that list to the pullimage task, which will go over the list, and will bring
image by image using sftp. After that is done, the erasefromlist task will
be called (if set to do so) for deleting the images that were pulled from
the remote list. After that, the list of pulled images (now local ones) will
passes to the postprocess task (if set to do so), which will perform over
the list of images the selected postprocessing. The ones currently implemented
are just for demo purposes, but the idea is that it can perform over the
images any desired action (like flipping, or substarcting a flat, etc). After
that, it will start all over again.
The parameters from the main menu are:
PACKAGE = arcview TASK = getimages deleteol= yes delete old list of images on host? (dbshost= wirc) host where the images are (dbs host) (dbsport= 1300) Port of service on host (user = wirc) user to login (imslist= images.list) file to write list of images from host (imspull= images.got) file to write list of last images pulled (logimag= yes) log all images pulled (imslogf= images.log) file to write log file (all images) (sleepti= 20) time between pollings (secs) (postpro= yes) post process images (epar postproc) (delreml= yes) delete image list on remote host? (verbose= yes) verbose operations (fd = ) (mode = ql)
deleteold: When the script starts, it will
ask the remote database for the image list. If a non-empty file is found,
it will prompt the user whether to bring those remote images, or to delete its from the remote
image list. This parameters says what to do.
dbshost, dbsport: address (or name) of remote host, and port
on remote host.
user: user name to loggin in the remote machine.
imslist: file where to get the list of images gotten from the
remote dbs.
imspulled: file where to write the list of images just pulled
(last time).
logimages: whether to generate a log file with all the images
than have been pulled.
imslogfile: name of the log file to generate if the logimages
parameter is set.
sleeptime: polling time for getting the images (seconds).
postproc: would you like to call the postproc task, to be run
over every image succesfully pulled?
delrem list: if set, it will use the "get image and delete
name on remote list", if not set, it will use the "timestamp" mechanism.
verbose: do everything verbosely.
fd, mode: internal use.
The other important parameters file is the one from the pullimages task.
PACKAGE = arcview TASK = pullimages (dbshost= wirc) host to get images from (user = wirc) user to log in (logimag= yes) log a list of all images succesfully pulled (imslogf= images.log) file name for log file (imslist= images.list) file with list of images to pull (replica= yes) try replicating directory structure also (imgpath= ./) directory for images (locimsp= imagesloc.got) file to log last images pulled (local name) (remimsp= imagesrem.got) file to log last images pulled (remote name) (lasttim= ) timestamp on last image pulled (output) (thistim= ) time when last image pulled was written HERE(ou(verbose= yes) verbose operations (fd = ) (mode = ql)
Not described before, are:
replicate: if set, it will try to replicate locally the remote directory.
imgpath: if replicate is not set, then this is the directory for leaving
all the local images.
8. Custom WIRC Scripts: focus, snap, wcenter, wcal
focus: focuses the telescope.
cl> wirc wi> focus PACKAGE = wirc TASK = focus (finc = 0.1) focus offset (pics = 20) number of focus frames (exptime= 10.) exposure time (ra = 15) RA offset (dec = 15) DEC offset (delfoc = no) delete old focus data from focus directory? (autoexa= yes) start imexamine automatically? (stploop= yes) prompt after each focus image? (status = 0) Status for script (mode = ql)
finc: focus increment in millimeters. You want to try to start the focus
script with a focus value ~ 0.5 mm lower than true focus, and then run the script with
positive increments. 0.1 mm is a good step size in reasonable Ksh seeing at Palomar.
pics: the number of images the script will take. IRAF crashes if you try to
stop a script with control-c, so best to choose a large number and then exit gracefully
later using stploop once you think you have a good focus.
exptime: exposure time. 10 seconds is good for reasonable Palomar seeing.
ra: telescope offset between first two images in RA arcseconds.
dec: telescope offset between first two images in DEC arcseconds.
delfoc: delete any old focus data? When the script starts, a focus subdirectory
is created in your working directory and all focus data is written to this subdirectory. When
you run the script a second time, focus data can be deleted or added to what's already there.
autoexam: start imexamine after each image is displayed? If not, the script
will continue to completion and you will have to investigate each image manually.
stploop: pause after each imexam session (or each image display if autoexam is off)
and prompt to continue the script. This is the best way to exit the script if you have found
a good focus.
When the focus script starts, a focus subdirectory is created and all
focus data is written
in this subddirectory as focus0001.fits and foc_diff1.fits.
The camera GUI parameters are saved,
but NOT used (ie: exposure time, basename, etc).
When the focus script finishes, the telescope is moved back to the
starting position, the
working iraf directory is re-established, and all camera GUI parameters are restored.
If the focus script crashes for some reason (hitting control-c,
hitting an unrecognized key
during the script or imexam), then you will have to manually return the
telescope, manually
backup to the iraf working directory, and manually restore camera GUI parameters (sequence
number in particular).
snap: Subtracts the last two images in your working directory, then
displays the result.
cl> wirc wi> snap PACKAGE = wirc TASK = snap (basenam= wirc) name of file prefix (autoexa= yes) start imexamine automatically? (buff = 2) ximtool display buffer (mode = ql)
basename: the basename for wirc images, from the camera gui.
autoexam: start imexamine automatically?
buff: display buffer, if you want to avoid automatic display in buffer 1.
wcenter: moves a point of reference (star) from one location
to another (center).
cl> wirc wi> wcenter PACKAGE = wirc TASK = wcenter (X_array= 2048) Size of array in X, as set by ROI (Y_array= 2048) Size of array in Y, as set by ROI (center = yes) Move to center of array? (Xpos = 1024) Move to X position, if not moving to center (Ypos = 1024) Move to Y position, if not moving to center (mode = ql)
X_array: the size of your WIRC array in the X direction as specified by the
Region Of Interest (ROI) button. 2048 is the default.
Y_array: the size of your WIRC array in the Y direction as specified by the
Region Of Interest (ROI) button. 2048 is the default.
center: move the reference point to the center of the array? Most people will
use this script to quickly center a pointing star.
Xpos: if not moving the reference point to the center of the array, move to
this X position.
Ypos: if not moving the reference point to the center of the array, move to
this Y position.
wcal: sets up WIRC to take dome flats and darks.
cl> wirc wi> wcal PACKAGE = wirc TASK = wcal (flat = yes) Take domeflats? (flatnum= 9) Number of images for each filter (dark = yes) Take dark images? (darknum= 9) Number of images for each dark SET (mode = ql)
flat: do you want to take domeflats? Once the script starts, if this is yes
you will be prompted for the total number of filters you want to take. You will then be asked
which filter to use, the exposure time for that filter, and whether you want to take flats with
the lamps off (useful for H & K bands). You need to know exposure time before you start
the script.
flatnum: the number of images to take for each filter.
dark do you want to take darks? If this is yes, you will be asked for the
number of SETS of darks that you want to take, for example 3 (one set each for J, H, K).
You will then be asked for exposure time and number of coadds for each set.
darknum: the number of images to take for each set of darks.
9. Appendices
9.a. Software Tree
This document describes briefly how the different software pieces are distributed.
The root is always called ArcVIEW (normally it is on /home/ArcVIEW).
Starting from here, the most interesting directories are:
Modules
Contains all the dynamic loadable modules, one per each specific operation/hardware. Inside any Module directory there is a README file which explains in more detail the specific Module. The most important for Palomar are:
Hardware dependent:
Astro-SDSUII: San Diego State University controller, generation IIP200TCS: Interface Module for connecting to the P200 Telescope Control Systemwirc-filter: Module for handling the WIRC filter wheels
Process-dependent:
Logical: contents sub-modules for handling:DCS: standard Correlated-double samplingFOWLER: fowler-sample and COADD processing
General Modules:
Unscrambler: Module for unscrambling the data. This module support several geometriesFits: Module for generating single or multiple-extensions fits files on diskRTD: Real Time display module, which can use Ximtool or DS9 as image displayersbuffermanager: For handling all the memory-related issues
Plug-Ins
Contains all the dynamic loaded plug-ins, for expanding the functionality of the main GUI. The most important for Palomar are:
- PI_TCSP200Gui: for handling all the P200 TCS-related commands. This PI serves basically as an User Interface to the P200TCS Module (it is basically the GUI which connects to the P200TCS Module).
- PI_WircFilterGui: for handling all the WIRC filter-wheel related commands. This PI serves basically as an User Interface to the wirc-filter Module (it is basically the GUI which connects to the wirc-filter Module).
- PI_ScriptServer: This plug-in serves as an interface between any external, socket or file base client, and the rest of ArcVIEW. This is needed when using external scripts.
More important for the engineer:
- PI_LabMain: GUI for handling all king of low-level commands (as writing to DSP memory locations, writing to Controller DACS, etc.).
- PI_ViewLogs: for seeing all the logs messages on real time.
- PI_voltages: monitors and log the different power supply values on real time.
ArcVIEW_Application
All the code for the actual server.
ArcVIEW_GUIS
All the code for the main GUI.
Logs
All the Log files produced by the system are here. Normally every GUI and module produce a Log file, normally identified by the name of the module or PI which produced it.
All the configuration files. Every plug-in has a configuration file, and most of the Modules too. All the Configuration files are ascii-based one, normally of the Windows-Ini type of file
Common
Here there are several subdirectories with common and utility functions. The two most important directories here are:
Command Processor: This has inside it one Labview library for each Module. This are basically the API for each module (which defines the commands for interfacing its).
CommLibrary: The code for the Soar Communications Library, used for handling all the communication between the Server and the Clients (the Server and the GUI, in the WIRC case).
9.b. Hardware InterConnection
Here we are showing some very basic diagram on the interconnection of the different pieces of hardware.
General diagram.
Motor controller connections.
Detector Controller
As shown on the right, the communications between the Host computer and the controller electronics (SDSU-II controller) is done using a fiber optic link between a PCI card on the computer and the timing board card of the controller. All the image data, and command/response transactions are performed using this two-lines optical fiber (one receiver, one transmitter).
The controller is connected to the detector through a set of external cables (4 videos, 1 Clock cable, 1 Bias cable).
As shown on the right, the communication with the motor controller box is done using the RS-485 protocol. The physical media used is fiber optic.
The little gray box on the back of the host computer is a transceiver that converts both physical media and protocol. It translates RS-232 to RS-485, and it goes from a normal electric cable to fiber optic. For this reason, this box is connected to the RS-232 port of the computer.
At the other side of the fiber optic line, there is another transceiver which receives RS-485 from the fiber optics and return RS-485 on normal electrical signals. Inside the motor controller box, then, there are basically three elements:
- Transceiver fiber-optic to cable (RS-485)
- Two PIC-STEP controllers, one for each filter wheel
The motor controller box is connected with the actual motor driver, which in turn receives its power from the Pharo box. This motor driver is connected to the WIRC wheel motors.
TCS communications
All the communications with the P200 TCS are done using the network (RJ-45 ethernet port).
9.c. Persson Standards
INDEX 9101 BS9101=P525-E 00 24 28.3 +07 49 02 J2000 9104 BS9104=S754-C 01 03 15.8 -04 20 44 J2000 9105 BS9105=P530-D 02 33 32.1 +06 25 38 J2000 9107 BS9107=P247-U 03 32 03.0 +37 20 40 J2000 9108 BS9108=P533-D 03 41 02.4 +06 56 13 J2000 9116 BS9116=S840-F 05 42 32.1 +00 09 04 J2000 9118 BS9118=S842-E 06 22 43.7 -00 36 30 J2000 9122 BS9122=P161-D 07 00 52.0 +48 29 24 J2000 9123 BS9123=S427-D 06 59 45.6 -30 13 44 J2000 9126 BS9126=P309-U 07 30 34.5 29 51 12 J2000 9131 BS9131=P035-R 08 25 43.8 73 01 18 J2000 9133 BS9133=S495-E 08 27 12.5 -25 08 01 J2000 9134 BS9134=P545-C 08 29 25.1 +05 56 08 J2000 9135 BS9135=S705-D 08 36 12.5 -10 13 39 J2000 9138 BS9138=S852-C 09 41 35.8 +00 33 12 J2000 9139 BS9139=P091-D 09 42 58.7 59 03 43 J2000 9141 BS9141=S708-D 09 48 56.4 -10 30 32 J2000 9142 BS9142=P212-C 10 06 29.0 +41 01 26 J2000 9143 BS9143=P550-C 10 33 51.8 +04 49 05 J2000 9145 BS9145=P064-D 12 13 12.0 64 28 56 J2000 9148 BS9148=P266-C 12 14 25.4 +35 35 55 J2000 9149 BS9149=S860-D 12 21 39.3 -00 07 13 J2000 9150 BS9150=S791-C 13 17 29.6 -05 32 37 J2000 9152 BS9152=P133-C 13 58 40.2 52 06 24 J2000 9153 BS9153=P499-E 14 07 33.9 12 23 51 J2000 9155 BS9155=S867-V 14 40 58.0 -00 27 47 J2000 9156 BS9156=P041-C 14 51 57.9 71 43 13 J2000 9158 BS9158=P272-D 14 58 33.1 +37 08 33 J2000 9160 BS9160=S870-T 15 39 03.5 00 14 54 J2000 9162 BS9162=P177-D 15 59 13.6 47 36 40 J2000 9164 BS9164=P565-C 16 26 42.7 +05 52 20 J2000 9166 BS9166=P330-E 16 31 33.6 30 08 48 J2000 9169 BS9169=P138-C 17 13 44.5 54 33 21 J2000 9170 BS9170=S875-C 17 27 22.2 -00 19 25 J2000 9177 BS9177=P182-E 18 39 33.7 49 05 38 J2000 9178 BS9178=S808-C 19 01 55.4 -04 29 12 J2000 9182 BS9182=S813-D 20 41 05.1 -05 03 43 J2000 9183 BS9183=P576-F 20 52 47.3 +06 40 05 J2000 9185 BS9185=S889-E 22 02 05.7 -01 06 02 J2000 9186 BS9186=S893-D 23 18 10.0 +00 32 56 J2000 9187 BS9187=S677-D 23 23 34.4 -15 21 07 J2000 9188 BS9188=P290-D 23 30 33.4 +38 18 57 J2000
9.d Image Puller Graphical Interface
9.d.i. General Explanation
Initialization Face
When it starts, it tries connecting to the local ArcVIEW.
If it can't comunicate with it, it will display an error message and will keep on a loop FOREVER trying to establish communication. It will get out of that loop only when it can communicate, or when the QUIT button is pressed.
When it comunicate, it will ask for all the parameters, like host address, user, etc, and will write it to the Control display (see GUI description). After that, it will ask the local ArcVIEW to get the image list from the remote machine. If the local ArcVIEW cannot comunicate with the remote ArcVIEW database (DBS), it will return an error message, and the GUI will remain in a loop asking for remote communication untill it reaches it or the QUIT button is pressed.
Once the local ArcVIEW communicates with the other, it will return a list of image names from the remote DBS. If the list is empty, the initialization face go to the last stage. If the list is not empty, meaning that there are images on the remote list, then it will prompt the user what to do with the list of images: forget or bring its. If the user says "forget", then the image names will be deleted from the remote DBS, so next time they will not appear; if the user says "bring", then nothing is done, and the initialization face goes to the last stage.
The last stage on the init procees is now to request the local ArcVIEW to start the loop for asking the list every "pollingtime" seconds. The it goes into the main loop.
Main Loop
The system will keep in a loop, asking the remote DBS for the list of images. Everytime an image list is gotten, then it will go and get all the images on that list using Secure FTP (no password is asked ... see this important note on the subject ). Now, there are two implemented mechanisms for avoiding getting the images again once they are on the local disk:
- deleting the image name from the remote list: everytime an image is succesfully written on the local disk, the system can ask the remote DBS to delete from its list that image (just the name from the list, NOT THE IMAGE), so next time it will not appear on the list at will not be pulled out. It is important to note that deleting the name from the remote machine does not mean much considering that you can specify a local "image log file" of all the images that have been pulled, and since the remote DBS is keeping the list for this specific purpose. The DBS is capable of keeping a completelly separate log file for another purposes, if desired.
- Using a timestamp mechanism: everytime a list of images has been pulled, it will grab the timestamp of the last image, and the next time it will ask for images "older than" the last timestamp. In this way, the remote DBS will have untouched its list and will send only the desired image names on the list. This is needed if more than 1 reduction machine is getting the data, for example.
The system will remain on the loop untill the QUIT button is pushed.
Finalization face
After the QUIT button is pushed, the system will clean up and will shutdown all activity.
9.d.ii. Graphical Unit Interface Description
Front Panel
The present GUI is used as a front-end to the ArcVIEW IMPUL Module, which basically is capable of pulling out images from a remote host holding an ArcVIEW database module (DBS). The IMPUL Module can be used undr ArcVIEW or as an stand-alone program.
Image puller GUI.
The present document will describe only how to use the GUI; the internals
are described on a different document (developers document).
The GUI has basically two areas: Status and Control Area.
Status Area
This is a upper part of the GUI (from top to the Info line).
The right part, under the Status History label holds the whole history of events, since the GUI was started. It will keep in there any error ocurred on the past as well as all the images that have been pulled out.
The left part, has, in the top, a display which has the current status; basically if it is waiting for new images, or fetching images, or any current error status.
This status will be added to the history list once it is not "current" anymore (so it will pass from left to right).
The second display, labeled as command response will display the response to any command sent; a command will be ANY modification to ANY GUI control, because the information is sent when any change in the GUI controls is produced. This means that the feedback of a requested change will be inmediate.
Then, there are four LEDs:
Fetching Images: it will turn green every time an image is being fetched to the local machine.
waiting: it will be green every time the system is waiting for new images (normally green between pollings).
pause: it will turn green and will blink if the systme is in pauses, which means that it is not getting images (see the Pause button explanation below).
error: it will turn red if any error ocurred. The actual error message will be displayed on the current status display.
After that, there are the following fields:
Last Image: The last image that was succesfully pulled out (meaning that it is already on the local disk) will be displayed. The display will include not just the image name, but the local path also.
Last Remote TimeStamp: It has the timestamp on the remote list for the last image gotten. This computes the time when the images was added to the list on the remote machine (meaning the time when the image was writen to disk on the remote machine).
Last Local TimeStamp: it is the time when the last image was localy written.
Control Area
Replicate Remote Dir: It says if the system should replicate (or try to) the remote directory structure. If checked, it will try to leave the local image on the same relative place it was on the remote machine. If the directory structure does not exists, it will try to create it. If the box is not checked, or it fails in creating the remote directory structure (permissions errors, for example) then it will leave any image on the path specified (when unckecked an image path control will apear). If it is unable to leave the images even on the path specified, it will keep trying, giving an error (error led on) and beeping so the user pay attention to it.
LOG: It says if the user can log a list of all the images succesfully gotten, and file log file name. It will store the image name and the timestamp. Disabled if unchecked.
host address: address of the remote host (from the where the images will be pulled out).
user: specify the user to loggin on the remote machine for getting the images.
port: specify the port on remote host where the DBS is servicing. It normally goes to 1300.
Polling Time: time, in seconds, for asking the remote host for new images.
Pause: If pushed it will leave the system in "Pause" mode, which means that it will not ask for new images. It will remain on this condition untill the button is unpushed. The paused LED on the status area will turn green and will blink on this condition.
Quit: Stop program. It will stop all activity and will close the GUI.
Questions? We've answered many common observing and operations questions in our observer FAQ page.
Please share your feedback on this page or any other Palomar topic at the
COO Feedback portal.
WIRC Manual / v 2.0.1
Last updated: 29 March 2019 ACM/CMH
|
|