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:


  1. Basic components of the system
  2. Starting and shutting down the system
  3. Main GUI
  4. Filter GUI
  5. TCS GUI
  6. ROI GUI
  7. Scripting
  8. Custom scripts: focus, snap, wcenter, wcal
  9. Data Reduction Machine
  10. Appendixes
    1. Software tree
    2. Hardware connections
    3. Persson standards
    4. Image puller GUI

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.

For more information about ArcVIEW itself, see http://www.ctio.noao.edu/instruments/arcview.

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.


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.


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) 
    DO coadd TIMES { 
        IF (STOP coadd) 
        DO fowler TIMES 
        DO fowler TIMES 
        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

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.

Filter GUI.

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

  1. Configure the serial line;
  2. Configure the two motor controller cards on the remote (Primary focus) motor controller box (PIC-STEP);
  3. 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.


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


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 
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 the filterpars file.
  • 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) the observe script for taking the images and the teloffset one 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. In the future this file will be automatically filled asking to the Filter Module the installsed filters.

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.cl script (this script is calling observe and teloffset) or observe.cl (this is calling teloffset, telfocus and filter) 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.cl
  • pullimages.cl
  • erasefromlist.cl
  • postproc.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. Data Reduction Machine

9.a. General Information

As an add-on to the WIRC System, a reduction machine is configured for the data pipeline. The idea is that this machine does not affect and it is completelly transparent to the acquisition machine.There is a task running on this machine for getting all the new images acquired through the net, automatically, using sftp. This means that the reduction machine pulls the data out instead of having the acquisition machine pushing it.

In this way, if the link is not working, or the reduction machine is down, the acquisition machine is not affected at all. We may say that the acquisition machine does not even know of the existance of the reduction machine.

The system works basically in this way:

There is a database on the ArcVIEW system, a module called DBS. This database is a general purpose module which holds variables of general interest for all the rest of the system. This DBS module has, besides the internal port for the other modules, an external TCP/IP port for servinbg external requests.

One of the things the database can keep track of, is the images that has been written to disk. If set for doing so, the FITS writter module can send to the Database any new image that was written to disk. In this way, the DBS mantains a list with all the images that have been written. There is a set of commands that the DBS module accept for handling this list of images.

In the Data Reduction Machine, then, can run any software for communicating with the DBS module on the acquisition machine, so it can know which images have been written and where they are; this is the only information this machine needs in order to pull the desired data out. Any software that can use a socket for communicating can then do this.

As examples, two "applications" has been created, intended onlly for starting and demo purposes; more complex applications can be built in the future by the interested parts:

  1. Iraf scripts: a set of Iraf scripts for polling the data has been created. Documentation on this Iraf scripts can be found on the Scripting section, and on the scripts files itselfs ($HOME/irafpkgs/arcview/imageList/*).
  2. an ArcVIEW-based application was created too. An specific arcview module was created for remotelly getting the data. This application is a module that can be loaded on any ArcVIEW application. This module basically knows how to talk with the DBS module through the socket. The idea then, the reduction machine can starts a local ArcVIEW with just this module (IMPUL module) loaded. This module will talk with the remote DBS module and can talk also with a local DBS module, if running. So in a more complex situation, it can bring the images from the acquisition machine, and in turn send the names of the images gotten to the local DBS, which in turn will keep track of all the images now on the local disk. A third machine can now run another IMPUL module and get the images from the local machine, forming a daisy-chain. Of course normal application will not requiere such complexity, but it can be naturally done. A little GUI was created for handling this module on the reduction machine. Documentation on that GUI can be found here.

Another thing that now can be done os to mix the rpovided Iraf scripts with the provided ArcVIEW module provided. Since the Iraf scripts can talk to a DBS, if the local ArcVIEW is running a DBS module (besides the IMPUL one), the script can talk to the local DBS and process the images as they are arriving, so we will have a task just getting images (ArcVIEW) and another postprocessing it in parallel (Iraf scripts).

As was said before, all this are just demos that can be improved, modified or completelly replaced as needed.

For a more general information, the list of available DBS commands for handling the image list through the net are described here.

9.b. Starting the Data Reduction Software for Pulling the Data

It is important to note that both machines, the acquisition and the reduction machine has exactly the same software.

This means that both machines can be run as either reduction or acquisition machine, meaning that the purpose of the reduction machine is dual: in normal times, it will be used as data reduction machine, but in case the image acquisition machine dies, for any reason, it can be swapped and act as data acquisition machine.

There is nothing to do in order to configure the machine as reduction or acquisition; it will detect inmediatelly if the acquisition PCI card is installed or not, and will autoconfigure according to that.

So for starting the software for getting the images:

  1. If you will use that iraf scripts, then just start a cl window and type getimages on it (epar getimages for configuration).
  2. If you are going to use the GUI, then just start ArcVIEW in the same way it is done on the acquisition software, and it will start ArcVIEW configured as an "image puller" rather than as an "image acquisition" system.

9.c. Technical Information

The WIRC data reduction machine is a dual Xeon Processor running at 3.06 GHz. It has 3 GB of RAM and about 130 GB of free HD.

It is a dual head monitor, configured as a unique monitor (Twin View).

It has a SONY DRU500A DVD writter drive, which speeds are:
DVD-R, DVD+R: 4x

Operating system: Linux RedHat 8.0
Software packages installed for recution purposes includes Iraf 2.12 and IDL 5.6

10. Appendices

10.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:


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 II
  • P200TCS: Interface Module for connecting to the P200 Telescope Control System
  • wirc-filter: Module for handling the WIRC filter wheels


  • Logical: contents sub-modules for handling:
    • DCS: standard Correlated-double sampling
    • FOWLER: fowler-sample and COADD processing

General Modules:

  • Unscrambler: Module for unscrambling the data. This module support several geometries
  • Fits: Module for generating single or multiple-extensions fits files on disk
  • RTD: Real Time display module, which can use Ximtool or DS9 as image displayers
  • buffermanager: For handling all the memory-related issues


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.


All the code for the actual server.


All the code for the main GUI.


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


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

10.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).

Motor Controller

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

10.c. Persson Standards

10.d Image Puller Graphical Interface

10.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:

  1. 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.
  2. 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.

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

Please share your feedback on this page or any other Palomar topic at the COO Feedback portal

WIRC Manual / v 2.0
Last updated: 18 July 2017 CMH