Date: Thu, 14 Nov 2019 14:51:15 -0700
Subject: Re: [sloan-25mlog 4769] 2.5m obslog 20191113 (SJD 58801)
From: "Daniel Oravetz"
If one or both of these events turn about to be the result of a
TCC-supplied slew path that would've resulted in a runaway slew in
previous MCP versions, then I would agree that we would prefer to have
this "new" behavior where the telescope does *NOT* actually act upon such
a slew trajectory; if it receives a bad slew path, just stay put, don't
run away and slew wildly.
However, I do think we should probably implement some sort of louder, more
immediate, handling of such a case -- let us know the slew will fail and
don't even let the TCC timer run as if the slew is actually happening. For
example, the old out-of-closed-loop event was a clear sign that the
telescope did not, or would not, get to where it was commanded and it
demanded immediate intervention to correct the axis state and reattempt
the slew. The way these failed slews behaved last night, they basically
acted as though they completed based on the TCC timer and the axis-state
(Slewing, then Tracking).
Under the current conditions, I wonder how a "bad" slew would be handled
during a pointing model, for example. We used to get on the order of ~6
out-of-closed-loop events during a typical pointing model and we would
correct the axis condition and re-attempt the slew. If the telescope
doesn't actually fail loudly enough now when a given axis does not/will
not make it to its commanded position, then it seems plausible the
exposure will just proceed as though the telescope actually *is* where it
should be. It should be clear during the TPOINT reduction to reject bad
exposures in these hypothetical cases, but it would be better to fail a
potential bad slew quickly and loudly so we could re-issue the slew
attempt, for example.
Dan
>>
>> =====
>> Notes
>> =====
>>
>>
>> (2) 10:47Z-10:49Z - During the commanded slew from 121,45,135 to
>> instChange
>> (121,90,00), altitude stayed at 45 deg. The MCP showed that the altitude
>> axis
>> was live and initialized, but altitude never moved from 45 deg. The next
>> attempt
>> at slewing to instChange resulted in altitude moving as commanded.
>> Please see
>> the Problems section for details.
>>
>> During afternoon checkout there was a similar missed slew at 23:15Z in
>> which the
>> telescope was at 121,90,00 and commanded to 121,30,00, but it stayed at
>> 121,90,00 despite STUI showing the status of the axes as 'Slewing.' See
>> Problems
>> section for details.
>>
>
> We'll look at this in more detail today, but at first glance it sounds
> like it is doing what it is supposed to under conditions that might have
> previously resulted in a wild slew.
>
> The afternoon one is a bit more suspicious to me due to it being a regular
> track command, those have been less troublesome that sop commands.