Date: Sat, 11 Mar 2000 14:13:59 -0600 (CST)
From: James Annis
Subject: Re: 51614 10Mar00 SDSS nightlog
On Sat, 11 Mar 2000, Scot Kleinman wrote:
> The second exposure never
> officially finished reading out and didn't get transferred to /data/spectro
> on host as it should have. See details below.
> PROBLEMS IN DETAIL:
> ===================
>
> Incomplete spectro read:
> -----------------------
> Plate 8 second  exposure never came back saying it was done.
> This is what the pool looked like:
>
> 51614     3024.1   -g----s    8239616  11-Mar-2000 10:28:00.37 TAI
> 51614     3024.4   -g----s    8720544  11-Mar-2000 10:28:00.37 TAI
> 51614     3024.3   -g----s    8239616  11-Mar-2000 10:28:00.37 TAI
> 51614     3024.2   -g----s    8239616  11-Mar-2000 10:28:00.37 TAI
> Error:
>
> Subsequent attempts to do a goStare failed, saying it was busy.
> endStare -force and iccExec $active readoutAbort didn't clear the problem,
> so we rebooted the crate and it came back to life.  Still the exposure
> never did get transferred.
The frame lacks the "completed" flag, so the DA didn't receive enough lines
to finish the frame. The teamster only retrieves completed, non archived frames.
It is likley the frame was no good.
I am very surprised that readoutAbort didn't work. When you get daqBusy or
"already busy" complaints, try doing a
	sop> iccExec $active statusDump daqBusy
then issuing the
	sop> iccExec $active readoutAbort
and then the
	sop> iccExec $active statusDump daqBusy
again. I'd like to see these.
The special thing about the spectrograph DA is that there are two VCI+ to
receive the data (from two spectrographs) on one CPU, so there are two
daqBusy's, three actually, the 0'th one being an OR of the other two.
It may be possible that the readoutAbort is only clearing one of the
VCI+ daqBusy's. I'll have to talk to Ron to refresh my memory.
But if it happens again, try the above, and cut and paste it into the log
or bug report, please.
jim