Regarding your comment "There is one thing we need to consider. What should be the rotator's behavior if it does not receive a new track command in the slewing?":

In the long run we want the controller to go into a fault state if it has to extrapolate any tracking command. This is independent of whether the controller happens to be slewing or tracking. In fact I would say it is more important if the rotator is slewing, because the rotator is moving more quickly.

I am not sure what your current changes do. If they do not stop slewing then please file a new ticket to stop slewing if tracking commands don't arrive in time.

Approved based on your description of the changes made.

Thank you for tackling this difficult problem.

I think the MOOG's original idea is that if there is an interrupt of track command in the slewing, it is safer to finish the slew instead of picking up the new track command (which might be different from the initial one) in a latter time. While I am reviewing the document now, I notice this might be what LSST want originally:

We may need to discuss the behavior we want together in a latter time. This might be related to the pointing's component behavior as well.

Hi TeWei, 

I don't think it is safe to finish a slew if you loose track demands, quite the opposite indeed. Specially if you consider that during a slew you are moving at higher velocity. If something out of ordinary is happening (e.g. demands disappear), the safest thing is always to stop.

Also, I am not sure that it what the slide says. The item you highlighted seem to suggest that the rotator will stay in "slew" mode until it reaches "tracking conditions", which makes sense. The item above says the position is updated based on the command (e.g. demand) at 20Hz and the item bellow says it will update the target position based on target motion, which also makes sense.  

Tiago Ribeiro If you think the powerpoint makes sense to you, the behavior of rotator is what I said. And this contradicts with your first paragraph. Thanks!