User`s guide

FLAMINGOS at the MMT
(Now it counts down for 10 seconds before applying the power).
..RPC-3>logout
Now run initflam.pl at the flamingos1b prompt. You do not need to close any of the daemons to rerun
initflam.pl for this problem. At the start initflam.pl will complain that the motor and mce4 daemons are
not up and listening, and ask if you want to continue. You do want to continue, as the daemons were
working properly before the crash of MCE4. MCE4 must be reinitialized, in order to set the proper
clocking of the array. You need to set the bias for imaging or for spectroscopy (enter i for imaging, or s
for spectroscopy when it prompts you). After it has successfully initialized the EDT frame grabber
(where it says do you see 10 lines of text between a line saying opening pdv unit 0 and a line
saying done), it will ask if you want to continue. You can type n at this point (typing y will just launch
another array temperature gui).
Next, you need to take two junk frames with short exposure time (e.g. 3 seconds). The first frame after
repowering and initializing MCE4 is not good, and taking a second frame makes sure that it looks
normal.
b) Problem: The image acquition counts past the exposure time without reading out an image.
Solution: This problem rarely happens anymore. With our previous slower version of flamingos1b, it
would sometimes take an extra 5 to 10 seconds to finish reordering the pixels, i.e., applying the look up
table, or LUT, before it writes the image to disk. In the MCE4 daemon window you sould see string of
dots being printed out during the apply lut phase:
UFEdtDMA::applyLut> . . . . . . . . . .
You should watch for several seconds to see if this line is present, and that it is printing additional dots.
When it finishes, it should also print something similar to:
UFEdtDMA::takeAndStore> close mmap file:
/data0/mmtguest/Test/test.0002.fits
UFEdtDMA::> completed: 1 -- /data0/mmtguest/Test/test.0002.fits
ufgtake> acquired frames: 1
UFEdtDMA::takeAndStore> close mmap file:
/data0/mmtguest/Test/test.0002.fits
UFEdtDMA::> completed: 1 -- /data0/mmtguest/Test/test.0002.fits
ufgtake> acquired frames: 1
If this never appears, try typing ufstop.pl -stop -clean at a flamingos1b prompt. Then try
taking another image; if that fails see if ping iocomm returns with the message that the iocomm is
alive. If the iocomm is alive, try rebooting MCE4 and reinitializing. If that completely fails, call for help.
c) Problem: A large number of error messages are printed out either when trying to move a wheel (e.g.,
with config.filter.grism.decker.wheels.pl), or during the first part of an image
acquisition, where it sends commands to MCE4.
Solution: It's possible that the iocomm has crashed, or is very confused. Try ping iocomm from
flamingos1b; if there is no response, it needs rebooting. Even if there is a response, it may be advisable to
18/23