As noted on DM-25243 the path generator probably interpolates between track (position, velocity, time) commands. If so, then the system should probably go to FAULT if time > the time of the most recent track command – in other words as soon as the path generator can no longer interpolate and has to start extrapolating instead.

This is different than I said earlier, but I think it's well worth considering. It means that the margin is given by how early we send our track commands – in other words the pointing component determines the margin, not the Rotator controller.

If there is the communication problem between the pointing component and rotator controller for somehow that no new track command is received, we may still need to put the rotator into the Fault state for the safety.

Yes. I agree. I was suggesting that the time be based on the time of the most recent track command – when current time > the time in that command then the rotator stops and goes into FAULT. In practice that would give us a margin of a few 10ths of a second – it depends on how many tracking command we send in advance, but I can't imagine sending more than about 5.

After the update of DM-25243, use the same simulation condition as the ticket's description, the rotator shows the following behavior:

The rotator does not enter the Fault state even there is no new track command after the time=6.05 second. This implies that there should be a threshold to put the system into the Fault state if the difference between the position command and position is big.

When we consider how to put the system into the Fault state, we need to separate this problem to two cases: (1) before the slew is done, and (2) after the slew is done. There should be no big problem for the case (2). However, for the case (1), we will face the same problem as DM-25441 after we clear the error and put the rotator back to SlewingAndTracking sub-state because the value of LsstCmdSet is not updated yet.

It looks like I could not just resolve this ticket by updating the code in ts_rotator_controller because the rotator will not be able to stop smoothly if I do not go through the update of Simulink model. When the rotator is in SlewingAndTracking sub-state, I need to trigger the errorIsTrue==1 to put the system into the ControlledStopping sub-state to calculate a smooth trajectory to stop. After the rotator stops, the Enabled state will transition to the Fault state (need errorIsTrue==1 and stopComplete==1).

At this moment, only three items can trigger errorIsTrue:
(1) rotatorTelemetry_signal.Flags_followingError
(2) rotatorTelemetry_signal.Flags_positionFeedbackFault
(3) rotatorCommands_signal.StateCommands_errorCheck

The (3) is not a good choice. This means I need to use (1) or (2) or create a new telemetry signal.

Add the new telemetry flag: noNewTrackCmdError in the Simulink xml file. Update the state machine to trigger the errorIsTrue if Flags_noNewTrackCmdError==1. Test the idea in the following to make sure the system will be in the Fault state after the simulation is 12 second:

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? There are two options:
1. The rotator continues to slew to the target, stop, and enter the Fault state.
2. The rotator stops, and enters the Fault state.

I think the option 1 is better because the behavior will be the same as DM-25243. For the option 2, we will have the same problem as DM-25441. 

Update the model to allow only 5 lost track commands (~0.25 second). This is based on the flag of noNewTrackCmdError. The figure is in the following:

The rotator enters the Fault state after the slew is done (the final track command is at time=6.05 second).

After some consideration, I think it is better to use the track state instead of the complete of slew as one of the criteria:

Clear the error of noNewTrackCmdError by the clearError command. This is the StateCommands_stateTrigger=6 actually. Put the final track command at time=6.05 sec and clear the error at time=11 sec. Put the system back to the SlewingAndTracking sub-state and make sure the system can enter the Fault state again in the track state as the following:

Test the condition that the final track command is at time=9.5 second as the following:

Magnify the region that loss the track command:

Please help to review the PRs:
1. https://github.com/lsst-ts/ts_mt_hexRot_simulink/pull/7
2. https://github.com/lsst-ts/ts_rotator_controller/pull/6

This ticket updates the Simulink model. You could just base on the ticket comment to do the review or I could show you the update by slack.

Thanks!

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!