Instructions for Operating the IRTC at the Telescope
by J. Hill, I. Foppiani, and R. Green
- Open xterm; issue startirtc2 command (or startirtc1 if you are using the other one).
Login: testcamera / Password: xevacamera
- Switch in lower right treehouse (left door as you face them) labelled "IRTC2 power supply" (normally on)
- Click on the icon for the IRTC GUI if it isn't already running.
- In IRTC GUI, for startup:
- Enable peltier cooler by checking the box, set camera temperature to 245
- Set the FITS path in the camera control text box to r:
- Check filter, FOV, red/yellow/green status block
- In IRTC GUI, for shutdown:
- Disable peltier cooler by unchecking the box
AO Test Camera Operations Manual
The full operations manual is here: 609g009
Turning on the Computer
The computer (irtc1 or irtc2) is located in the LRTH (Lower Right TreeHouse). if the computer has been off for some time and the ambient temperature is below freezing, the computer will not boot properly at first. A telltale is that the HDD activity light in front of the computer will blink once, pause, and then blink three times, in a repeating pattern. You cam also verify that the computer does not respond to pings (from an xterm, try ping irtc1|irtc2
). If that is the case, just let the computer run for a while and power cycle. It may take a few times.
Turning On the Camera
Turn switch in the lower right treehouse (left door as you face the treehouse) labeled "IRTC2 power supply".
Connecting remotely to the Computer
On the Linux computer of choice, open a terminal window and type "rdesktop -u testcamera -g 700x840 irtc2 -z". (This is aliased as "startirtc2" for user LBTO, lbcobs, telescope.) That action should bring up a pop-up login. (The -z sets compression, but we haven't measured whether it helps or not).
Note that this action logs out any other version of rdesktop running at the time.
Double Click on the Windows desktop icon for the IRTC GUI if it isn't already running.
The square icon on the top right of the GUI should start yellow and then go green. If it goes red, there is a problem connecting to the motor controllers.
- Check that the power cables are properly connected between the Power Supply box and the camera. Beware of the fact that we have found instances of cold solder joints inside the connectors (cf. IT#8037)
- Check that the GUI is connected to the correct serial port. The computer has two serial ports: COM1 and COM2. The serial port number can be found in the "editConf" window (via "Edit config..." on the File menu of the IRTC GUI). Click on the "Camera Box" tab, and look for the "Serial port" field.
Taking Images during the night
The toolbars are relatively self-explanatory for direct operation of the camera. Set the exposure time in microseconds, the frame rate for multiple exposures, and the number of exposures if desired. The exposure time is the controlling variable if the two are in conflict. For actual rapid framing (not immediately relevant to active optics commissioning), the frame rate for very short exposures is limited to the range of 15 to 60 frames per second. The system is such that the frames will be taken with the exposure time and speed requested, but then are transfered to the local (PC) disk individually, which takes some time. There is a check box to enable the Peltier cooler, which should be on for lower dark-current operation.
Typical maximum exposure times at H are 3-5 seconds before saturation.
The optics configuration toolbar shows a status indicator box - green, yellow, or red; a choice of one of three check boxes sized indicatively for the three different fields of view, a choice of filter position, and a lens configuration file. In order to get a valid configuration, the filter must be selected first
then the field of view. If the configuration is undefined (e.g., by changing the filter and not re-checking the field of view box), the status box may still be green, but an error message will appear under the image display window. Alternate lens configuration files are given, in case future use patterns calls for that, but it is recommended for now to use the default configurations.
There are several modes for taking data. Movie mode (by clicking on the movie camera icon) frames continuously using the given exposure time. The pull-down menu from the down arrow button allows for saving (on the camera's local disk) single exposures, a sequence of multiple exposures, or looping repeatedly through the set exposure sequence, saving everything until the process is stopped by clicking on another mode. To take a sequence, set the exposure time in the first box in the toolbar and the number of exposures in the third box. (Turn off movie mode, if not done already.) If desired, type a prefix in the right-hand box on the lower toolbar. Press the button to the right of the box with the number of exposures to record a sequence. Multiple exposures are saved as FITS datacube files.
When the IIF-based higher level control is used, a single exposure is saved to the /Repository/ directory accessible to the mountain network. Such an exposure has a full FITS header with all the desired telescope information. Multiple exposure datacubess are saved usually on the local disk, and can be saved to the Repository (or another directory of choice) after initially creating a link to that directory on the control PC.
Mounted Network Disk
On 20080415, Jim Davis has added a network drive (R:) on the IR test camera PC that maps directly to the repository directory on the NFS server, via Samba. This should connect whenever you login to irtc. To send irs-generated sequences directly to the Repository, set the FITS path in the camera control text box to 'R:'.
Obviously, images stored on the local disk can be transfered to the Repository as well by dragging and dropping from C:\SNAPS\FITS\relevant data directory. For good housekeeping, it then might be worthwhile to create a subdirectory in the Repository: there is one called EF being used for early experiments. The locally stored images (not retrieved through irs) do not have full telescope information in their FITS headers.
One toolbar allows the creation of up to three user-defined regions of interest in the detector format. When activated, the detector readout is limited to those subregions, allowing yet faster frame rates. There is also a zoom-unzoom button that affects the magnification shown in the display window. Both of those toolbars are typically hidden, to allow more of the image format to be visible.
TROUBLE SHOOTING Mapped Network Drive
If the R: drive mapping is broken do this to reestablish it...
Bring up a "Windows Explorer" window.
Select the "Tools" menu.
Select "Map Network Drive" option.
In the "Map Network Drive" window...
Select "R:" from the "Drive" drop down selection list.
Enter "\\archive\newdata" in the "Folder" field.
Select the checkbox to reconnect at restart
Set the user id to be used for the connection.
Select "Connect using a different user name".
In the "Connect As..." window...
Once this is done the drive will be mapped.
Enter "LBTO" user id in the "User name" field.
Enter the password for the "LBTO" user in the "Password" field.
At the "Map Network Drive" window...
Turning Off the Camera
When the control window is shut down. it leaves the Peltier cooler in whatever state its check box indicates. To preserve the lifetime of that cooler, it should be turned off when the camera is not in use, by unchecking the enable box before closing down the control window.
Normally the power switch in the treehouse is left on all the time during normal observing operations.
The IRTC computer's dns entry name is "irtc" or "irtc.mountain.lbto.org" with IP 10.144.0.100.
The computer and power supply are located in the lower right treehouse.
(Another computer which is also configured for aluminizing is available as a spare.)
There are two typical failures beyond things which can be cured by rebooting the PC.
Program fails to connect to the motor controllers
Program fails to connect to the camer
We have seen occasions where the "irs" socket interface is unable to retrieve images from IRTC. If this problem is persistent, the suggestion is
to reboot the IRTC windows machine.
email from Italo Foppiani on 28-April-2008:
We carried out a series of tests on our TCP server to find out the
reason of the slowness issues happened on the mountain and I would like
to summarize here some clarifications/recommendations on the use of the
TC control software and its socket connection.
The Xeva camera dll doesn't foreseen a specific command to acquire a
single image but it just allows to start and stop the images acquisition
in the memory buffer. To acquire the a single image the acquisition has
to be stopped after the first image has been taken but if the
second image is already being integrated, which is very likely, the stop
command becomes effective only at the end of the acquisition of the
Since we have to wait that the acquisition is stopped before reading an
image, the time needed to acquire a singe image is at least
longer than 2 times the exposure time set. This is basically of no
effect on milliseconds exposure images but could be relevant for images
with exposure time of seconds.
The timeout of the client application waiting for the images on
the socket connection should be set at least at 2 times, but 3 times
would be better, the exposure time.
The main aim of the socket connection is to provide a "software"
connection to the TC control software to trigger the images acquisition,
i.e. to take images without clicking on the GUI which would have meant
hundreds of clicks for the AO tests.
Since the the thigh schedule to develop our software, the TCP server
was simplified as much as possible and is not be able to
manage multiple connections (see my email of the 4th of April 2007 to
Norman Cushing). The handling of multiple connections was reduce
to the fact that any connection to our server would reset any
previous one just to have a simple way to reset any stuck connection.
The new connection does NOT reset the the commands previously sent
through the socket.
When the control software receives a command through it
accomplishes the task and returns the data (if any) on the current
connection regardless it is or not the same connection through which the
command has been sent.
This means that if the client sends the GetImage command and then goes
into timeout because of the long delay needed, especially in case of
seconds exposure images as explained, and if the client establishes a
new connection to the server, it will receive the data requested on the
old connection before receiving any new message and/or data! This could
cause a delay and/or error on the client side.
During the characterization of the camera I heavily used the GetImage
command, hundreds of times for each session, without noticing any
problem of the ones happened on the mountain. It has to be noted that I
used just one connection during my tests: I established the connection
at the beginning of the tests session and I closed it at the end.
In my opinion the best strategy is to always use the same connection to
the server and foreseen a suitable long timeout (3 times the exposure
time set) on the client side because sooner or later the server always
puts data on the socket.
Anyway in case of error I suggest to wait for a proper long time (3
times the exposure) and clean the current connection pipe. If instead
the current connection is closed, the client should wait for the proper
time before opening a new one.
Moreover any time a new connection is opened, be sure the old one is
properly closed on the client side also in case of timeout, otherwise it
remain pending in "fin_wait" status for tents of seconds. Even if it
should not affect the current connection, a number of old connections
pending could waste hardware resources. The status of the connections
could be checked by means of a free software as TCPView
I suggest to use it to monitor the socket connections especially when
the control PC becomes very slow, just to check whether there are to
many old connections pending.
Should the irs data taking procedure start timing out because of socket problems, it could be that the test camera PC needs rebooting. To do that type Cntrl-Alt-Del to bring up the 'task manager' Then select 'restart' from the Shutdown menu. Of course, the remote desktop window will disappear, and you need to keep trying the rdesktop command (as above) in Linux until the login reappears. If the camera control window does not appear inside the remote desktop window after logging on, double click on the LBT-IRTCCS icon to start it up. Set the camera temperature to 245 and click the enable box to restart the Peltier cooler. All the toolbars may appear, in which case, you can hide the two seldom used ones, after zooming to fill the window with the image display.
When displaying the rdesktop remotely, some systems intercept the Cntrl-Alt-Del so
you can't bring up the irtc Windows task manager. If you need to reboot in this situation use the
"Run" option on the program menu to run the command 'shutdown -r -t 00'.
Hint: We've found that IRTC is happier if the machine gets rebooted about once a week.
From: David Thompson <email@example.com>
Date: Fri, 11 Apr 2008 15:09:14 -0700
I get for the Xenics XEVA-320 camera (30um pixels):
3" FOV 210 mas in 600 um so f/42.86 (FOV = 3.3 x 2.7 arcsec)
6" FOV 402 mas in 600 um so f/22.39 (FOV = 6.4 x 5.1 arcsec)
25" FOV 2012 mas in 600 um so f/4.47 (FOV = 32.2 x 25.7 arcsec)
This will vary a little bit depending on the input f/ratio (f/15.0
assumed). If this does not sound right to anyone, let me know!
- 13 Apr 2008