This is the first time we are sending the night log using Eric's new logTool. We have been having some difficulties using it and if tonight's log looks funny, please bear with us. Day Work: As soon as the day crew had finished correcting the imager safety latch problem, French & Steph stowed the imager in the doghouse and mounted the engineering camera. Steph tried talking to the camera and got a ppk 68 error. After checking that the order in which to power up eng cam components was correct, she still got the error, so Craig was called in. Tracing back from the camera, we eventually found that the paralan at the guider mac was bad. It was replaced with a spare, and the eng cam is working. Craig will ship the faulty unit to the manufacturer. This leaves us with one spare on site. New fiducial tables were built and installed to MCP v5_3_1. There are now no missing fiducials in the tables for any of the axes. Not surprisingly, there were some differences between the current and last az table (Bill & Jon B. worked on the az fiducials during the shutdown). The current tables should be the baseline for future comparison. On a happy note, there were fewer error messages about the az latch not being read. I think I only saw four errors per sweep. The first two sweeps in increasing altitude, the 15-degree fiducial was not seen. There was no problem reading it when traversing in decreasing altitude. The next three sweeps, it was read in both directions. French was notified. He said that the fiducials had been cleaned, but he would have someone look at them again tomorrow. MCP v5_3_1 was declared as the test version. logTool: We could not find the doc for logTool in the IOP page linked from procedure page v1_22. Am I missing something??? While trying to save my log entry, I got, Error:window name "logview3saveprompt" already exists in parent Later I found a window asking about saving the log under other windows. Maybe that is what the above referred to. The popup window that asks you questions when you hit "Load", "Save", or click "Editable" many times come up at a location not so close to the window where I had the "logTool" window up. With the many many windows we need to operate, this makes it very easy to loose the small popup window behind others. Dan could not see the log Atsuko put into the log section of logTool. Dan also could not add anything to the log section, even if she unchecked the edit button or even quit logTool. I would like to be able to spell check and also load a file to any of these categories. Telescope:Mirrors were homed and primary was relaxed. M2 galil E actuator later complained it could not stop on a full step. This was after it had been homed and was attempting to adjust collimation during tracking. Rehoming the D and E actuators solved the problem. It did not recur. Seeing ranged from 1.1 to 1.6 arcseconds. Best focus was -450 ( no corrector in place ). Collimation was checked and looked pretty good, though the need for some small tweak may be seen when the imager goes on. The instrument block for the engineering camera was checked and found to be in good shape. We managed to get at 72 point model in before the clouds came and closed us down. The fit of the data to the existing model showed a 15 arcsecond RMS error, mostly in altitude. When the parameters were allowed to change, the fit became 1.7 arcseconds, about as good as it gets. The pointing model is implemented, but yet to be tested. We closed 1:20 due to clouds. There was lightning to the east and southeast at the time. The clouds continued to thicken. By about 04:00 there were radar echoes very nearby although the rain sensor has yet to go off. Landru: Landru is great! I enjoyed having so many screens in front of me where I can see many windows at once. Craig and Scot spent time configuring so that GNOME will be convenient for our use. But we found out that we could not use GNOME due to the color map problem we have with TPM. Until the problem is resolved, we will have to use KDM as our window manager. Gnome to work with TPM color map will be nice. I managed to get the left mouse button STUCK in down position. I used my fingers to pop it back up, but a brand new mouse should not do such a thing! I ended up executing commands I didn't meant to in a harmless window, but it can potentially be dangerous. In IOP, arrow key no longer game me previous commands. But in the xterm, it works. Arrow keys for previous commands will be nice. KDM does now allow us to drag windows from one virtual desk top to another. It will be nice if we could do so -- other we have to always remember to start this process and that process at different virtual windows which is tedious. TPM: Running TPM display on Landru: As mentioned above, color map problem is a pain ---- for now, run KDE as your window manager if you want to get the TPM display running. We did not get others to work. Peregrine, any schedule on when we can get the color map problem solved ? For things that Peregrine requested us to shake, o Wind direction/speed [NEW] - the TPM software is in place but the hardware is in the process of installation. --> Yes, the display is there and there are numbers in the display for them. We assume the current numbers displayed are just noise. o Slip detection [NEW] - many problems here, some stemming from the fact that the system only latches the data available to me for 5 microsecs. Glenn is considering a redesign of that interface to make the data more persistent. --> What do we expect to see when all is well? I see the display and many flashing lights on the amplifier status display. The SLIP detection is 0x0. In an IOP window, we saw the following message, but we (including Eric) did not understand what it means. Does anyone know what it means? It seems nothing bad happened, but we are curious to know what it means. im> CA Exception was: Network connection lost Context was: sdsstpm.apo.nmsu.edu:5064 When op=5 type=-1 count=0 im> DAs: At the beginning of the night, I placed tapes in the archiver as usual and then started a bias drift. I then realized that I forgot to do a tapeLoad. There were also some other bias runs taken earlier that day by Jon B., so I stopped the run and did " initNight -tapeLoad" which spent a long time "blam-o"ing because the drives were considered to have "NoTape" or in "NotMount" status although they were loaded prior to the bias drift. IOP tried blam-oing 181 times and then restarted trying to it again (the counter restarted). Finally when iop gave up initNighting, I tried to flush the Q since the Watcher indicated that the Q was nonzero. IOP told me I cannot do so unless the archiver is paused. So I tried to pause the archiver, but the archiver status did not change and the tapes are either in "not Mounted" or "no tape" status. We also saw in the murmur log many "loading tapes" messages for all the drives, but the archiver status showed that the tapes were not loaded successfully. This exact same thing has happened before few times --- usually after someone did "goDrift" with the archiver disabled. After trying pausing, loading/unloading the tapes few times, we found out that if we load the tape and do nothing for a while (many minutes --- I was away from my terminal and watching Dan take pointing model for about 20, 30 min before returning to my erminal), the archiver will pause. It seems that it just takes longer than one thinks for the archiver to pause. With the archiver paused, we executed "archFlushQ", "initNight -poolInit" successfully. When we proceeded to do "tapeRelabel", IOP said that "IOP ready for flight", but Watcher and "statusDump archDrvSts" showed that id4-1 was in the "Reading tape label" state and not "Ready to Archive". Reloading the tape few times did not clear the situation and we noticed the following message in the murmur log. Aug 06 23:09:49 sdssid4 dArchSrv dsc_I_archFailMsg Rimfire failure ID = 1 Status = 0xf0008001 0x5080 Aug 06 23:09:49 sdssid4 dArchSrv UNKNOWN_MSG Unknown message code, 800140DB, received Aug 06 23:09:49 sdssid4 dArchSrv dsc_E_archNoLabel Tape does not have ANSI 3 label So we decided to reboot the id4 to 6 (there is no way to reboot only id4-1). We tried "tapeRelabel" again and got the same message as above. We then decided to reboot and put in a new tape in id4-1. This time it worked and we had all the drives ready to archive. It will be nice if the imager was used during the day without the tapes, the Q is flushed so that we don't get into this situation again. And the observers should make it a habit to check the Q depth before putting in tapes or doing "initNight" so that in case the person who did a drift before the the observers forgot to clear the que, we still do not end up in this situation as we saw tonight again. We saw the "Error: extra characters after close-brace" after the endDrift. Here is the message with the "tb". im> endDrift Tue Aug 07 02:05:33 MDT 2001: stopping drift with: iccExec id1 id2 id3 id4 id5 id6 ad1 ad2 ad3 ad4 readoutEnd Tue Aug 07 02:06:15 MDT 2001: closed shutters Tue Aug 07 02:06:15 MDT 2001: endData completed Flavor of this run (science, bias, calibration, engineering, ignore, help) [bias]: Invalid flavor Please try again Flavor of this run (science, bias, calibration, engineering, ignore, help) []: ignore Stripe, Strip (e.g, 22,N or SS,N) [100,O]: Mountain estimate of the overall data quality (unknown, bad, acceptable, good) [unknown]: bad leap seconds = 32 Error: extra characters after close-brace im> tb extra characters after close-brace while executing "if {[catch {summarizeIdReportForLog [mjd4Gang] -runNumber $run} summaryProblem]}..." invoked from within "if {$mark=="end"} { if {[catch {summarizeIdReportForLog [mjd4Gang] -runNumber $run} summaryProblem]}{ murmur "problem sending run inform ..." (procedure "idReport" line 217) invoked from within "idReport end" reportComment [askObserver $scanFlavor $scanStripe $scanQuality $scanComment] idReport end saveLs ..." (procedure "endDrift" line 58) invoked from within "endDrift" SoS: running and fine, it seems. invoked from within "if {[cameraType] == "imager"} {