Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-25245

Put the Rotator into Fault State if no Track Command for a Long Time

    XMLWordPrintable

Details

    Description

      If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we do see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

      The following is the figure to show the simulation result (detail is at DM-25243):

      The system is at the Fault state around time equals 20.2 seconds (no new track command after time=6 seconds).

      Attachments

        Issue Links

          Activity

            No builds found.
            ttsai Te-Wei Tsai created issue -
            ttsai Te-Wei Tsai made changes -
            Field Original Value New Value
            Epic Link DM-23800 [ 431613 ]
            ttsai Te-Wei Tsai made changes -
            Link This issue relates to DM-25045 [ DM-25045 ]
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell).  If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink mode by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result:

             
            ttsai Te-Wei Tsai made changes -
            Attachment track_v0_1_long_enterFault.png [ 44217 ]
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink mode by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result:

             
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink mode by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result:

            !track_v0_1_long_enterFault.png|thumbnail!
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink mode by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result:

            !track_v0_1_long_enterFault.png|thumbnail!
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink mode by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result (detail is at DM-25434):

            !track_v0_1_long_enterFault.png|thumbnail!
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink mode by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result (detail is at DM-25434):

            !track_v0_1_long_enterFault.png|thumbnail!
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink mode by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result (detail is at [DM-25243|https://jira.lsstcorp.org/browse/DM-25243]):

            !track_v0_1_long_enterFault.png|thumbnail!
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink mode by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result (detail is at [DM-25243|https://jira.lsstcorp.org/browse/DM-25243]):

            !track_v0_1_long_enterFault.png|thumbnail!
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink mode by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds.
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink mode by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds.
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink model by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds.
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink model by the simulation experiment, but we do not know how is that decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds.
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds.
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds.
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is the figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds (no new track command at time equals 6 seconds).
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is the figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds (no new track command at time equals 6 seconds).
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is the figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds (no new track command after time=6 seconds).
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we did see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is the figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds (no new track command after time=6 seconds).
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we does see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is the figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds (no new track command after time=6 seconds).
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we does see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is the figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds (no new track command after time=6 seconds).
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we do see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is the figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds (no new track command after time=6 seconds).
            ttsai Te-Wei Tsai made changes -
            Description If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This time could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we do see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is the figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds (no new track command after time=6 seconds).
            If the rotator does not receive the track command for a long time, the rotator should be put into the Fault state. This could be 0.5 second (by Tiago) or 1 second (by Russell). At this moment, we do see this in the Simulink model by the simulation experiment, but we do not know how that is decided. In addition, we did not see this when we did the test on summit. This task needs to figure out what is the existed logic in model and how to update it.

            The following is the figure to show the simulation result (detail is at DM-25243):

            !track_v0_1_long_enterFault.png|thumbnail!

            The system is at the Fault state around time equals 20.2 seconds (no new track command after time=6 seconds).
            rowen Russell Owen added a comment -

            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.

            rowen Russell Owen added a comment - 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.
            rowen Russell Owen made changes -
            Link This issue relates to DM-25243 [ DM-25243 ]
            ttsai Te-Wei Tsai added a comment -

            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.

            ttsai Te-Wei Tsai added a comment - 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.
            rowen Russell Owen added a comment -

            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.

            rowen Russell Owen added a comment - 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.
            tribeiro Tiago Ribeiro made changes -
            Labels HexRot MainTelescope HexRot MainTelescope ccw-rotator-integration-test
            ttsai Te-Wei Tsai made changes -
            Status To Do [ 10001 ] In Progress [ 3 ]
            ttsai Te-Wei Tsai made changes -
            Attachment slewWithoutNewTrackCmd.png [ 44428 ]
            ttsai Te-Wei Tsai added a comment -

            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.

            ttsai Te-Wei Tsai added a comment - 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.
            ttsai Te-Wei Tsai added a comment -

            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.

            ttsai Te-Wei Tsai added a comment - 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.
            ttsai Te-Wei Tsai made changes -
            Link This issue relates to DM-25441 [ DM-25441 ]
            ttsai Te-Wei Tsai added a comment - - edited

            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.

            ttsai Te-Wei Tsai added a comment - - edited 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.
            ttsai Te-Wei Tsai made changes -
            ttsai Te-Wei Tsai added a comment -

            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:

            ttsai Te-Wei Tsai added a comment - 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:
            ttsai Te-Wei Tsai added a 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? 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

            ttsai Te-Wei Tsai added a 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? 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 . 
            ttsai Te-Wei Tsai made changes -
            ttsai Te-Wei Tsai added a comment - - edited

            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:

            ttsai Te-Wei Tsai added a comment - - edited 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:
            ttsai Te-Wei Tsai made changes -
            ttsai Te-Wei Tsai made changes -
            Attachment trackAndFaultAndClearError.png [ 44461 ]
            ttsai Te-Wei Tsai added a comment - - edited

            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:

            ttsai Te-Wei Tsai added a comment - - edited 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:
            ttsai Te-Wei Tsai made changes -
            ttsai Te-Wei Tsai made changes -
            Story Points 3 2
            ttsai Te-Wei Tsai added a comment -

            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!

            ttsai Te-Wei Tsai added a comment - 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!
            ttsai Te-Wei Tsai made changes -
            Reviewers Russell Owen [ rowen ]
            Status In Progress [ 3 ] In Review [ 10004 ]
            rowen Russell Owen added a comment - - edited

            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.

            rowen Russell Owen added a comment - - edited 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.
            rowen Russell Owen added a comment -

            Approved based on your description of the changes made.

            Thank you for tackling this difficult problem.

            rowen Russell Owen added a comment - Approved based on your description of the changes made. Thank you for tackling this difficult problem.
            rowen Russell Owen made changes -
            Status In Review [ 10004 ] Reviewed [ 10101 ]
            ttsai Te-Wei Tsai made changes -
            Attachment image-2020-06-22-10-58-59-157.png [ 44498 ]
            ttsai Te-Wei Tsai added a comment - - edited

            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.

            ttsai Te-Wei Tsai added a comment - - edited 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.
            ttsai Te-Wei Tsai made changes -
            Resolution Done [ 10000 ]
            Status Reviewed [ 10101 ] Done [ 10002 ]

            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.  

            tribeiro Tiago Ribeiro added a comment - 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.  
            ttsai Te-Wei Tsai added a comment -

            tribeiro 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!

            ttsai Te-Wei Tsai added a comment - tribeiro 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!
            ttsai Te-Wei Tsai made changes -
            Link This issue relates to DM-36861 [ DM-36861 ]
            ttsai Te-Wei Tsai made changes -
            Link This issue relates to DM-36872 [ DM-36872 ]

            People

              ttsai Te-Wei Tsai
              ttsai Te-Wei Tsai
              Russell Owen
              Russell Owen, Te-Wei Tsai, Tiago Ribeiro
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Jenkins

                  No builds found.