Hot News

This page notes recent updates, news which might not yet be incorporated into the manuals or problems encountered during observing runs which will (hopefully) be repaired in the near future. We intend to update this frequently.

18 October 2012: In October 2012, FLAMINGOS was disassembled in the 4-m coude clean room and the filter box was removed and brought downtown. There, the filter wheel was removed from the box and the K filter removed from the wheel. Verified K filter on the Lambda 9. The new James Rhoads low-background J filter (named JLo) was measured on the Lambda 9 and installed in place of the K filter in the wheel. The JLo filter is the same diameter as the K filter, but thicker, so the filter retainer was secured with spring-loaded screws which were secured in place with Loc-tite to prevent them from working loose. On 11 October, the filter box was taken back to the mountain, FLAMINGOS was reassembled and pumped down.

Attempted to rename K filter to JLo by editing files, but according to Nick, it is necessary to do some recomplilation, which I did not want to risk. Since the K filter was never actually used, we will simply use a note to inform users that the K location in the software is actually the JLo filter.

31 July 2012: We are considering removing the wide K filter temporarily to test an experimental low-background J filter, possibly during the early fall of 2012. Since the K filter has not been used in years, this should have no practical effect, but we are posting this just to notify the community.

9 December 2011: After the last repair (during which the MOS dewar held a good vacuum), the October observers noted signal variability as an apparent function of telescope position. This was at a very low level and probably would not have been noticed in general operation. The observers were carrying out exoplanet transit observations which permitted them to note these 1 - 3% variations. An electronic cause was postulated, but this seemed unlikely. Observations of the pupil using a defocused image in October showed field-dependent vignetting of the pupil which also depended on telescope orientation. This suggested that a foreign object was on the first element of the camera lens. The Camera Dewar was disassembled and a small 4-40 screw was found on the first camera lens! This had apparently come loose from the grism wheel bearing retainer. When the filter box was taken apart, a second screw was found as well. These were replaced (using Loc-tite) and all of the screws in the filter box mechanism were checked for tightness. We have no idea why these screws came loose on their own--all others were tight. A subsequent on-sky test showed a clean pupil image and no variation of background as a function of telescope position. The following monitoring observing run also showed no signs of the earlier problem.

26 September 2011: Two repairs were carried out on the MOS dewar during an observing hiatus. The home switch for the decker wheel, which had stopped working (see December 2010), was found to be still working, but the actuator on the decker wheel was missing the button on the home switch. The geometry was such that a shift of only 0.5 mm laterally would cause the actuator to miss the switch button, which was seen as a nonoptimal design. The limit switch was replaced by one using a conventional roller follower and offset so that activation would occur at the same rotation angle of the wheel. The actuator was replaced by a spring-ball screw with a wider footprint. These repairs give a much larger impact parameter for switch activation. The "Initialize Wheels" command may now be used with the Decker Wheel.

The MOS dewar has continued to give leak problems around the seal between the access flange and the cylindrical dewar itself, since the vacuum sealant designed to replace the rubber gaskets (see June 2010) did not perform as expected. The two pieces were separated, cleaned, and reassembled using the rubber gaskets again. During this repair, we found that the screws were apparently bottoming out in the tapped holes, so they were replaced by shorter ones. The access port is now securely fastened to the MOS dewar and the measured leak rate is about what one might expect from diffusion.

The "Abort Dither Script" function on the menu has been tested at both the 2.1-m and 4-m telescopes and functions properly.

The "mirror" script on the 4-m now coordinates with the save-the-bits archiving, so it is not necessary to run the old "Autocopy" script anymore.

21 March 2011: During the recent 4-m run, a spate of what appeared to be "bad" reads occurred, which were not cured by the usual MCE4 massaging techniques. The problem spontaneously went away and the instrument worked well afterwards. The problem was later traced to saturation of the array (the flatfield lights were on high intensity, rather than low) rather than to any problem with the MCE4. After looking into this, we have identified differences between saturated and "bad" images, which will be described in more detail on the FLAMINGOS User Information page.

Briefly, if one obtains apparently bad images which persist even after rebooting the MCE4, one should try to ensure that the images are not the result of array saturation:

• Check that the detector temperature is near the correct value of 77K
• Move the grism wheel to the "true dark" position and take an image. If the problem is saturation, it should go away.
• Check the image statistics. A saturated image will look similar to a bad image, but the mean signal level will be near 49000 ADU and the dark pixels in the lower left corner should be obvious. A bad read will have a signal near 57000 ADU and no dark pixels in the corner.

04 January 2011: During the last run at the 4-m, all of the shortcut buttons from the FLAMINGOS menu worked properly. However, we found that the temporary window generated by the menu scripts does not accept keyboard input, so it is not possible to abort an observing script. While we are looking into this issue, we therefore recommend that long observing scripts be initiated using the command line in the FLAMINGOS xterm window rather than from the menu. This will permit one to abort them using the standard keyboard interrupt procedure (^Z to suspend the script; "jobs" to list the processes, and "kill -9 %(job number)" to kill the script, as well as "ufstop.pl -clean -stop").

13 December 2010: During the setup for the run tonight, the Decker wheel ran away with the first (homing) motion and had to be halted manually. This happened a couple of times, making it evident that the home switch has failed for this wheel. I have carefully aligned the MOS decker position and used this to calculate the zero position. Until this is repaired, it is necessary that all Decker wheel motions be made using the "Move Wheels" command and NOT the "Initialize Wheels" command. It will be necessary to remove and open up the MOS dewar to replace this switch, so it may be some time until this is done.

8 December 2010: We have made some additional changes to the environment at the 2.1-m and 4-m telescopes. There is now a FLAMINGOS icon on the MacMini terminal which will bring up a command menu of some of the most often used commands which do not require arguments. Clicking on one of the buttons will execute the perl script command in a temporary window (e.g., the Take Image button will execute singleimage.pl). This should make observing less complicated and reduce the confusion associated by the various longer commands, particularly those for moving the instrument wheels.

Although the "mirror" command to move data from flamingos1a to the MacMini is recommended, one should also run the old "Autocopy" script to move the data to nutmeg when observing at the 4-m. This appears to be necessary to achieve the proper time registration of the NOAO save-the-bits postprocessing, at least for now.

3 November 2010: We have made some significant changes to the observing environment at both the 4-m and 2.1-m telescopes. At the 4-m, the old tan and nutmeg terminals have been replaced by two Mac-Mini computers named mayall-2 and mayall-3. Each of these two stations provides two large high-resolution monitors which operate as a single environment, eliminating the need to include those pesky display environment commands in the startup sequence. Any of the FLAMINGOS windows can be moved to any location on the two monitor screens. As before, one uses the MacMini as a host to run the instrument, which is still running on flamingos1a.

The MacMinis have 4 desktops (called spaces); if you move your mouse to the top right corner of the monitor on the right, or the bottom left corner of the monitor on the left, you will get a bird's eye view of all the 4 spaces and can pick one (or drag a window from one space to another). This is just a convenient feature, which some might actually find annoying, and can be easily changed (you can also switch to a different space by clicking on the "Spaces" icon in the Dock).

It will take some time to get used to a Mac and its nuances; one notable difference with Linux is that once you start an OSX application, terminating its open window does not kill the application; it just gets rid of the instance you were running (you will see the top menu bar still showing the app to be alive and well); and there are hot keys to start another instance, or kill the application. An odd ramification of this behavior is when you click on an icon in the Dock, expecting to start a new instance of that app in your current desktop, or space, like on Linux. but if that application is already running on another space, you will be automatically taken to that instance of the app! This is nice sometimes, and annoying other times :-) This default behavior can be modified a bit, but not much; bottom line: one has to learn some new tricks when using a Mac.

We have also installed a script which will "mirror" the data directory on flamingos1a to one of the MacMinis. Thus, if one is using mayall-2 as the observing interface to FLAMINGOS, one can run the mirror script on mayall-3 and it will run rsync between the data directory on flamingos1a and the selected directory on the MacMini approximately every 30 seconds. This can provide an additional backup (or replacement) for the "Autocopy" script and also permits one to look at the data using the IRAF tools installed on the MacMini. In addition, the MacMini monitors have two USB ports to which one can attach an external USB drive and transfer the data from the MacMini to the drive.

We have run FLAMINGOS successfully from the MacMinis at the 4-m and will be testing the operation at the 2.1-m later in November 2010. This is still a work in progress, and we will be adding additional features in the future. The User's Manual is being updated to incorporate the new startup procedures and we will report this on the Hot News page when they are done.

8 October 2010: We have leak checked the MOS dewar and found that the seal holding the MOS access port flange to the dewar does have a small but persistent leak. The leak is sufficiently small that fairly short (< 5 day) MOS runs can operate without the need to re-evacuate the MOS dewar, but we will be looking into repairing this more permanently when a sufficiently long block of time is available.

21 June 2010: During the past week we worked on both the MOS dewar and grism wheel. The access flange mount to the MOS dewar was secured by 10-32 screws bolted into tapped holes in the aluminum housing. One of these holes had stripped out and the others, upon investigation, were found to have been tapped only 3/16 deep, even though the holes themselves were closer to 3/8 deep. We used a bottoming tap to thread the holes all the way to the bottom. We reinforced the stripped hole with a steel keensert, deciding not to do this for all holes. We then reassembled the flange, using a special vacuum sealant in place of the twin rubber flange. As of now, this appears to be holding vacuum pretty well, but we will continue to watch this.

At the same time, we opened up the camera dewar and removed the mechanism box containing the three cold wheels; this was brought downtown for further work. The home switch was in fact damaged, as the plunger had never returned to the out position after the fatal motion command, leaving the switch permanently shorted. This switch was removed and replaced with a new one, which appears to work properly. The bearings on the grism wheel felt rough when the wheel was held vertically. In addition, all three bearings in the mechanism box cover were bad; two were quite rough and one was completely frozen. We ordered replacement bearings, degreased and relubed them with molykote and replaced them. After reassembly, the mechanisms turned freely and all limit switches activated. On 17 June, we reinstalled the mechanism box in the camera dewar and tested the mechanisms under computer control. After pumping and cooling, they were tested cold on 19 June and worked well. The grism wheel now operates repeatably in open-loop motions and senses the home switch in limit mode.

NOTE:Nick has written a couple of new scripts to replace the config.filter.grism.decker.wheels.pl and config.mos.wheel.pl scripts. Currently, the first of these was edited so that the defective home switch on the grism wheel was ignored, and the second of these did not incorporate any backlash correction, so that the MOS masks would be in slightly different orientation depending on the direction one approached from. The new scripts are:

• engineering.config.filter.grism.decker.wheels.pl: This is basically the same as the old config script, with the grism wheel home switch reinserted. When one selects one of the wheels, the script will also ask if you want to configure additional wheels. We recommend this script for the initial motion of a wheel, to make sure that the home is properly sensed.
• config.rel.mv.filter.grism.decker.wheels.pl: This command makes relative motions of the wheels without sensing the home switch. The positions are redefined as positive and negative with respect to the home position, so the wheel can move either way, in some cases making the motion much shorter. Backlash compensation is incorporated into this script.
• config.rel.mv.mos.wheel.pl: Since the home switch on the MOS wheel has been inoperative for several years, this script is the same as the config.mos.wheel.pl script, except that it does incorporate backlash compensation, ensuring that the mask orientation will not depend on the previous wheel position.

We recommend that observers use these new scripts. Depending on Nick Raines' schedule, we may rename the engineering command once we verify that it works well on the telescope

7 April 2010: We are continuing to investigate whether the grism wheel can be operated in the "near-home" mode, as is done with the MOS wheel. For some reason, the original code does not seem to support this. Bill Ball located the cause of the MOS dewar leak and it is now maintaining a good vacuum.

4 March 2010: During the last observing run, the grism motor went into a state of endless searching during a motion. Fortunately, the motor was not damaged by the long continuous motion, but it appears after investigation that the home switch for the grism wheel has become shorted. As a result, the controller thinks it is always at the home position. Switching the operation mode to "near-home", as is done with the MOS wheel, was not successful, and we are looking into a possible problem with the motor code. One can use the low-level 'ufmotor' commands to move the grism wheel, but this is quite cumbersome; we hope to have this repaired prior to the next observing run.

The MOS dewar also developed a serious vacuum leak in the middle of the last run, and we are starting to identify the cause of this.

8 January 2010: Updated the FLAMINGOS User Information webpage to emphasize the need for observers to submit their coordinates for MOS masks well before their observing run. The process of generating the masks involves several steps, including sending the files to the mask vendor, who has to fit the job into their (usually) busy schedule. Once the coordinate files are received here, they are checked and then converted to text files and sent to the NOAO graphics designer, who converts them to a machine-readable format (Gerber) and prints out the masks in pdf to be checked once again. The Gerber files are then sent to the vendor in Tempe. After the laser cutting, the masks are black anodized (the vendor found that attempting to cut masks in pre-anodized aluminum sheet resulted in ragged slit edges).

We are requesting that mask coordinates be submitted a minimum of four weeks prior to the observing run to allow time for checking the coordinate files (and iterating the mask design should problems be found), converting to the Gerber format, and allowing contingency for the vendor workload. Furthermore, since personnel at both NOAO and the vendor often take time off at the end of the calendar year, we strongly recommend a lead time of six weeks for observing runs scheduled in January. NOAO does not have the capability of cutting the masks, so late submission of the mask coordinates entails a risk that they may not be fabricated prior to the observing run.

The User Manual instructions for identifying and aligning a MOS mask on the field involve loading the mask design image (or DSS image) of the field and the region file on a separate buffer of the FLAMINGOS ds9 display. Recent observers used an alternate technique of displaying the field and region overlay on a separate laptop computer, which proved to be much more efficient, since the current FLAMINGOS image on the ds9 and the design field on the laptop can be directly compared to each other. We strongly recommend that observers with the ability to load their design field images and mask region files onto their laptop adopt this tactic in the interests of increased efficiency and reduced frustration.

19 October 2009: Bad amplifier channel which suddenly appeared on recent imaging run was investigated. Switching cables from preamp to A/D modules isolated the problem to the preamp. Bill Ball and Bill McCollam investigated the preamp carefully and found a broken ground lead on one video input (not related to the bad channel) and a bad solder connection on another amplifier channel (also not the bad channel). After reassembly, all channels worked; the bad channel was probably the result of corrosion in the preamp input connector, which did have some water spotting. There was insufficient time to investigate the noisy upper right quadrant, beyond establishing by switching the A/D cables that the problem is likely in the preamp. Since the digital-to-analog converters used for applying the offsets to the A/D converters each handle a full quadrant, this is a possible suspect. The output amplifiers and multiplexer chips each handle two and four amplifier channels, respectively, so they are unlikely to be the cause of a noisy quadrant.

rjoyce@noao.edu
31 January 2013