Date: Tue, 20 Apr 1999 13:16:37 -0600
From: Russell E Owen
Subject: Re: 2.5m obslog 990418 ( MJD 51287 )
>   In the short run, I could probably get a very good model by either
>waiting for three minutes after each slew before taking the exposure in
>collecting poining data, or by being able to take a pointing exposure
>without slewing ( a sort of TRACK/PTERR=(NOSLEW)? ).  Russell, is there a
>simple way to modify TRACK/PTERR to do one or the other of these?  In the
>long run, I suspect either MCP buffering to the MEI, or interpretation of
>TCC commands will need refinement.
Just for the public record:
- one can set a settling time after a slew in the TUNE block
- my guess is that the error is related to DRIFT not flushing the
typeahead buffer, in which case a better solution is to be sure to
AXIS STOP before each slew IF the slew has not been allowed to
complete. If this is done, the current settling time ought to be
sufficient.
Note that the standard pointing errors sequence should never leave
lots of old data lying around in the MCP's interpolated move buffer.
So if long lags are being seen during automated pointing, I'm less
sanguine about how to fix this.
>   We had quite a bit of trouble converging on a rotator angle. It was
>close to 0 deg obj.  However each time we'd try to correct the error it
>would look good for a few minutes, then rather suddenly it would go bad
>again, giving long streaks for stars.  This seemed to be correlated to the
>collimation update coming from the TCC.  I really doubt the problem was due
>to the routine itself and changing optics positions.  It seems more like
>either the MCP was misinterpreting the collimate command ( thinking it was
>something it should act on ), or possibly the collimate causes the MCP
>heartburn in missed frames or something.  In any case, once I turned off
>the collimate process we made a correction and it took and stayed.
Interesting. Note that the collimation process does NOT talk to the
MCP, so the MCP is off the hook for this one. Pointing errors are
likely due to the mirrors not going where they are supposed to.
One thing to try: set the # of axes to 4 for the primary mirror, so
the lateral links never go off air. I very much doubt this will help,
and suspect that the problem lies in the known-to-be-flaky M2
actuators.
In any case, contrary to what I told a few people earlier today,
turning off the collimate process does indeed stop the mirrors from
being moved about, even Robert's focus loop will have no effect on
the mirrors.
I have just gotten a Mac set up, and my goal for the rest of today is
to modify the automatic pointing error collection process to pause
after a star is not found (and permit retrying the star).
-- Russell