Date: Wed, 4 Feb 2004 09:24:41 -0800
From: Russell E Owen
Subject: Re: MJD 53034 Run 4388 Offset Problem
At 1:16 AM -0700 2004-01-31, Dan Long wrote:
>>Dan wrote:
>...
>It (the boresight offset) apparently failed because the telescope
>was not tracking when the offset was issued, even though the axes
>were initialized.  What makes this so surprising is that we haven't
>been bitten by this before. There was a "show obj" later which
>confirms that the boresight offset was never applied (it does show
>the large calibration offset issued to compensate).
Great detective work! Thanks for digging this out of the logs. You
are exactly right. The offset is rejected:
2004-01-30 09:02:15.880Z 4 7 > Started; Cmd="offset boresight
0.10483333333333333,0.,0.,0. /PAbsolute /Wait /Computed"
2004-01-30 09:02:15.980Z 4 7 F Text="new position rejected";
AxisNoSlew="TTT";
RejectedAxisErrCode="NoRestart","NoRestart","NoRestart"
in English it was rejected because the axes would not be moving
afterwards and the offset was issued without the /Restart qualifier
(not that I'm suggesting using /Restart; far from it; if the axes are
halted, you would end up slewing to some mystery location -- the last
slew issued -- which sounds really scary).
>Russell, is it correct that a boresight offset issued directly after
>an axis init will _never_ be applied even if the subsequent track
>command has /keep_boresight selected?
>
>If so, is there any reason for scanStripe not to issue the boresight
>offset _after_ the track command rather than before (the order has
>always struck me as odd)?
I agree that order would make a lot more sense from the TCC's
perspective. I hope it also works from an observing standpoint!
One could also imagine a change to the TCC such that offsets that
can't be applied are recorded, but this is a bit trickier than it
sounds. If the axes are moving and the offset is rejected then it
should be completely rejected, since it'll halt the axes. The only
time a rejected offset would want to be saved is if the axes are
already all halted.
I think the new algorithm could be: if the new offset makes any axis
halt, then it is rejected and not recorded. Otherwise it is recorded
even if it cannot be applied (e.g. because the axes are halted). I
think it's simple enough to be sane. The main worry is that one can
imagine somebody accidentally putting in a mistakenly huge offset
which then mysteriously messes up the next slew. Basically the offset
cannot be not properly sanity-checked before it is recorded.
I'm game to put that in *IF* the obs specs approve it.
However, I suggest not changing the TCC unless there is some evidence
this would help in more than this one case, since there appears to be
a trivial fix to this one case -- offset after slewing.
I have copied the 3.5m obs specs on this, as they are especially
likely to know how such a change to the TCC might affect routine
observing, and are especially likely to be affected by such a change,
whether positively or negatively.
Finally, I would like to note that the rejected offset was a failed
command. Surely SOP caught that? What happens during a procedure like
this when a command fails? If a command fails, whatever is wrong
should be fixed before continuing. It courts disaster to just plow
ahead and hope for the best. If "hope for the best" is the standard
SOP response to failures, I shudder to think what other errors are
hidden in the data.
-- Russell