From: sjnk@apo.nmsu.edu Subject: SDSS Night Log 51795 7Sep00 Date: Fri, 8 Sep 2000 06:09:11 -0600 (MDT) Thursday Sep 07 2000 Apache Point Observatory SDSS 2.5m Observing Log (MJD 51795) OBSERVING TEAM: =============== Atsuko Nitta Kleinman (APO) Scot Kleinman (APO) Anders Jorgensen (LANL) ---- PT VISITORS: ========= Scott Burles (FNAL) - phone Craig Loomis (APO) Robert Lupton esq. (PU) - phone Jeff Mader - 3.5m/SDSS Candidate Connie Rockosi (UC) - phone THE PLAN: ========= Shake up. SYNOPSIS FOR NIGHT: =================== A bug in SOP v3_18_1 PR filed) means it is not usable; we did test it, though, by sourcing a file from v3_17_5_4. The Calibs seem to work fine. We got additional data on plate 389 and spent a lot of time on bd17smear. The end result is something that works, but needs a bit more refinement. In IOP, we checked biasCheck and biasGen and found two mistakes, one of which we fixed. We will leave to Connie to check the appropriate 'host directories tomorrow for the appropriate op* files. We checked the new watchdog chiller code and it worked fine. The MCP MS.ON fixes all seem to work, although there were a few minor peculiarities which could also be our misunderstanding of what is supposed to happen. The new watcher was declared current, but not the new SIOP. TELESCOPE STATUS: ================= In dome with cart 8 mounted. DIMM: ----- not running. INTERLOCKS: =========== None bypassed. SOFTWARE USED: ============== IOP/SOP: v3_18_1 **NEW** Watcher: v2_8_5 **NEW** MCP: v4_3_3 **NEW** TPM: v2.0.0 AstroDa: 14_34 TCC: 2.4.0b2 WEATHER SYNOPSIS (see below for hourly data): ============================================= mostly clear; bad seeing. GENERAL COMMENTS (see Problems below for details): ================================================== While we were setting up, we noticed that the TPM was not logging. A startTpmLog command did not start the TPM logging and the tpm.dl display showed no numbers. We caught Craig who was walking out of the door to go home and begged for help. He found the cable from the J-C1 bulkhead connection at the top of the MCP/TPM to the transceiver at the back of the TPM was bad. He fixed that and we had TPM logging again. Hooray! We cut a new version of watcher, MCP, and IOP/SOP (poor watcher, with no capital letters in its name). See SOFTWARE above for version numbers. With Connie on the line (and computer) we tested the new watchdog (chiller failure) code and it worked fine. Connie closed the PR. We next played with the new MCP. We verified that no fiducial corrections are done when slewing with the MCP, but when issuing a TCC track command, MS.ON is asserted at the beginning of the slews, errors are corrected, then MS.OFF is asserted at the end. (This all seems right.) We didn't have any large errors which were ignored with our TCC slews, so we couldn't test that feature. We slewed multiple times from 14 to 89.5 deg in alt. and no complaints were issued about fiducial 6, which is something BHL warned us to look for. There were quite large accumulated errors when slewing up with the MCP, though. They generally de-accumulated on the way down, but did not cancel out completely. You can see the results in today's mcpFiducial.dat file, or if you want to see just the results from our practice slews, you can find a copy of the fiducial file at that point in ~sjnk/mcpfidtest.dat on sdsshost, at least until I delete the file next week. There were a couple strange things which are discussed further in the Problem section below. We tried our first goStare 0 -init -bias with the new SOP and found a bug (see problems below and filed PR), so sourced header.tcl from SOP v3_17_5_4 so we could test other new SOP features. While testing fk5InFiber after a loadCart (it should go to the nearest fk5 to the field center - a time-saver if we have to go to one anyhow to find our stars), the telescope aborted in azimuth multiple times. Repeated axis inits and fk5InFiber calls failed to clear the error. We only got it to work by using the McpMenu to clear reset the amps, clear the condition, and clear the brake. No PR was filed since we don't know what went wrong, but this kind of thing is not good. Tracing down the logic in the watcher interlocks displayed only revealed that either the brake was on or the permit was disabled. It revealed no root cause (which I find is often the case - more often than not). After re-booting the guiderMac which lost track of one of its drives, we got our fk5 star, thus confirming the proper behavior of fk5InFiber. We tested the new preCalib. The HgCd lamps came on as soon as the flat field exposure was reading out, but the Ne ones did not come on until after the flat read out. Is this what it is supposed to do? Per Scott's request, we continued gathering moony exposures with cart 8 plate 389 to a) see how much moon we can tolerate, and b) add a little more S2N to the moony data already gathered. We then went on to test bd17smear and found two mistakes which we fixed (a bad if syntax and a missing global declaration) and checked in on the mainline. Once fixed, bd17smear finished successfully, but was not very useful as it relied on the telescope pointing to at least place the target star in the guide fibers. It started with fiber 1, which is perhaps, a POOR (as opposed to WISE) choice since it's smaller than 10 and 11. So, I would suggest two possible changes: 1) start with fiber 11 and work your way down - this might allow the telescope a better change to get the centering right. 2) before the first smear, pause to let the observer center the star before beginning the automated operation. You may want to pause every other time as well, if we think we can't offset accurately. 3) actually, since you know the fiber angles, you could probably auto-center if you detect any starlight at all. We implemented 1), and 2) for fiber 11 only. It seems to work, but we might want to implement centering for all positions and I recommend a real SOPpie look at my checked-in code to make sure I didn't screw up any of the important logic. There was one thing I couldn't quite figure out and that's how to wait for the slew to begin. I tried something I still think should work, but it didn't. My only suspicion (besides incompetence) is that things might start and stop too soon for it to catch up. See my comments in the code. Once we settled on an appropriate kludge for the above, we could no longer see a star in the guider images. I suspect this was due to deteriorating conditions and poor pointing, but I suppose I could have broken something in the track command, but I don't see how since I didn't tough that at all! Anyhow, I checked in what I did, so have a look and we can try again in shakedown once you tidy up my mess. I'd really like to get the proper wait for slew to start line, though.... There was one additional problem: after it completed the last fiber's smear, we got a series of "I think we aren't slewing" messages. Where was it going and why? We didn't have time to work on this one.... We also tested the new biasCheck in IOP command and it seemed to work. Our biggest complaint is that biasCheck -help says nothing! Worse than that, it produces the following output as it trys to do something: Error: Can't find mjd for run -help in /data/photo/* We already have enough old commands without help strings. Let's not add new ones! biasGen also works and also produces the above unacceptable response to biasGen -help! We did find a bug in biasCheck where it was writing to stdin instead of stdout. We fixed that and checked it in. endNight -doSpectro seemed to complete OK, but grabInst -drop produced the following output: sp1> grabInst -drop {kill_teamster} setWindowTitle massacre_slaves {close file7} cameraAttachLogCleanup {close file11} unsetupPacketeer {grabInstruments -drop} {grabInstruments -drop} What? It did appear to successfully drop instruments, though. We had a problem exiting SOP. It said something about tccClose, then hung. We quit with a delete window mangager operation. DATA ACQUISITION (see IOP/SOP output below): =========================================== IMAGING: -------- Run Type --- ---- 1669 bias SPECTROSCOPY: ------------- Exposure Type -------- ---- 6541 flat 6542 arc 6543 science 900s 6544 science 900s 6545 science 900s 65* attempts at bd17smear MIRRORS: ======== PRIMARY: -------- MIGS outdated SHOULD BE Axial A= 1.9299 1.9310 Axial B= 0.5584 0.5585 Axial C= 0.5559 0.5560 Transverse D=0.3939 0.4065 Lateral E= 1.9164 1.9165 Lateral F= 0.4160 0.4170 GALILS Commanded:5150., -2950., 400., -5850., 14600., 14100 Actual: 5150., -2950., 400., -5850., 14600., 14100. SETMIR VALUES primDesOrient:0.00, -8.00, 11.70, 640.50, 439.70 primOrient:0.00, -8.36, 11.84, 640.32, 439.52 (0.0 5.0 11.7 640 128 from Sep. 2/MJD51790 log) SECONDARY: ---------- Focus:-300 Temp:18 Altitude:43 MIGS Axial A=-1.0000 Axial B=-0.8930 Axial C=-0.9499 Transverse D=-0.2090 GALILS Commanded:1141500., 1102900., 1173500., -3200., -8000. Actual:1141490., 1102813., 1173641., -3200., -8000. SETMIR VALUES secDesOrient:903.65, -20.00, -8.00, 50.00, 17.95 secOrient:903.71, -20.01, -7.99, 49.76, 17.80 FOCUS LOG: ========== M1 Piston M2 Piston Temp Wind Time Inst setmir TCC setmir Az Alt C Dir MPH filt FWHM " LN2 SCHEDULE: ============= Spectro filled at ~5:45. The imager dewar was down to about 45 pounds, so we replaced it with a new one at 06:00. PROBLEMS: ========= SOP goStare ----------- sp1> goStare 0 -init -bias PlateId [-9999]: Flushing charge for 15 sec appending BEGIN appending END 968381230 968381230 beginData has failed: can't read "flavor": no such variable Error sp1> tb can't read "flavor": no such variable while executing "if {$flavor == "unknown"} { # add offset information for diamond pointing offsets set keyword AZ_OFF set msg "Azimuth Offset (Diamond Pointin ..." (procedure "setSpectroHeader" line 231) invoked from within "setSpectroHeader " invoked from within "if { $cameraType =="spectro" } { setSpectroHeader }" invoked from within "if { $cameraType =="mt" || $cameraType == "spectro" } { # spend the few seconds necessary to do a camstat in order # to get headers right ..." (procedure "beginData" line 108) invoked from within "beginData $noIncrSeq" invoked from within "endStare -timeout 80 -daqWait" ("eval" body line 1) invoked from within "eval endStare "$imageName" -timeout $readoutTimeWait $flags" (procedure "goStare" line 469) invoked from within "goStare 0 -init -bias" sp1> We thought this might be because flavor was an undeclared global variable. So we made our own version of header.tcl and declared flavor to be global, but it didn't help. So, maybe it needs to be passed to setSpectroHeader. We proceeded testing other aspects of SOP by sourcing header.tcl from the v3_17_5_4 version. We filed a bug report. MCP and MS.ON ------------- We were getting LOTS of watcher errors with things like the following: Not disabling MS.ON even with error of 3 (max allowed: 0) (Sep 07 23:49:19) (Not disabling MS.ON even with error of 3 (max allowed: 0) (Sep 07 23:49:19): Sep 07 23:49:34 MDT ) At the end of our TCC slewing, we set the alt fiducial by hand at the fiducial #1 and got the following in the mcpFid.... file: ALT_FIDUCIAL 968392554 1 3825222 3825116 3824942 14.885 5877 UPDATE_ENCODER 968392568 altitude 3846296 106 SET_FIDUCIAL_ERROR 968392568 altitude 213 Where did the 213 come from? Shouldn't this be zero? A second manual fiducial setting a few moments later resulted in: ALT_FIDUCIAL 968392714 1 3825222 3825222 3825212 14.886 5877 UPDATE_ENCODER 968392726 altitude 3856197 0 SET_FIDUCIAL_ERROR 968392726 altitude 0 SET_FIDUCIAL 968392726 altitude 1 3825222 3856197 15.006 0 which looks as I expected. WEATHER DATA: ============= Wind Time Temp F Dewp F MPH Direction Dust DIMM Sky Precip. 20:01 61 36 16 76 (ENE) 555 21:01 61 36 12 81 (E) 601 22:01 59 39 22 83 (E) 760 23:01 59 39 18 91 (E) 806 00:01 59 38 14 94 (E) 919 01:01 60 38 16 112 (ESE) 1130 02:01 59 38 10 103 (ESE) 1260 03:01 57 39 12 84 (E) 1048 04:01 57 39 14 111 (ESE) 1287 05:01 59 39 8 108 (ESE) 1708 [pmt]cl = partly, mostly, totally cloudy DATA LOGS FROM IOP/SOP: =======================