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

Reply the Command Status of State Transition of Rotator Controller

    XMLWordPrintable

    Details

    • Story Points:
      3
    • Epic Link:
    • Sprint:
      TSSW Sprint - Dec 06 - Dec 20, TSSW Sprint - Dec 20 - Jan 03
    • Team:
      Telescope and Site
    • Urgent?:
      No

      Description

      Reply the command status of state transition of rotator controller. The controller should make sure the state transition is done or not in the Simulink model and reply the CSC. For the clearError command, there should be a timeout value in the configuration file that the result of command status will be based on the state in that timeout period (this is to avoid the misunderstanding of clearError command if the interlock is still triggered).

      For this task, the rotator controller should use the same thread of commanding.c to simplify the resource management.

        Attachments

          Issue Links

          is triggered by

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. DM-23849 Acknowledge the SAL Command from Rotator PXI

          • Done
          is triggering

          Story - Created by Jira Software - do not edit or delete. Issue type for a user story. DM-33068 Test the New Version of Rotator Code on Summit

          • Done

            Activity

            Ascending order - Click to sort in descending order
            Hide
            Permalink
            rowen Russell Owen added a comment -

            That sounds great. My thoughts:

            • The SET_STATE commands are most important for the CSC. It would be very useful if the low-level controller waited to ack the command until the state actually changed: ACK after it transitions to the right state, NOACK it it transitioned to the wrong state or fails to transition at reasonable time. That way the CSC can be confident the low-level controller is in the right state as soon as it sees the ACK. (Right now it has to keep reading telemetry until it sees the state transition – which I can keep doing, but it's a nuisance).
            • I really like your suggestion for CLEAR_ERROR: only ack it after you are fairly confident that the error has been cleared. noack if there is still a problem.
            • It would be nice if the stop and point-to-point move commands waited to ack the command until the transition started (e.g. the state changed to stopping or moving-point-to-point). However, I fear that may difficult, because the state may be very short lived. For example: what happens if the CSC commands a stop while the axis is already stopped, or if it commands a point-to-point move to the current position? If you can figure out a simple, robust way to handle this, great. If not, feel free to ack it based on the current criteria: "the command is compatible with the current state and the parameters are in bounds".
            • For the TRACK_VEL_CMD = 0x9031 command (which is received at 20 Hz) I suggest ack based on "the command is compatible with the current state and the parameters are in bounds". I don't think there is anything else you can wait for, and fast response is important.
            Show
            rowen Russell Owen added a comment - That sounds great. My thoughts: The SET_STATE commands are most important for the CSC. It would be very useful if the low-level controller waited to ack the command until the state actually changed: ACK after it transitions to the right state, NOACK it it transitioned to the wrong state or fails to transition at reasonable time. That way the CSC can be confident the low-level controller is in the right state as soon as it sees the ACK. (Right now it has to keep reading telemetry until it sees the state transition – which I can keep doing, but it's a nuisance). I really like your suggestion for CLEAR_ERROR: only ack it after you are fairly confident that the error has been cleared. noack if there is still a problem. It would be nice if the stop and point-to-point move commands waited to ack the command until the transition started (e.g. the state changed to stopping or moving-point-to-point). However, I fear that may difficult, because the state may be very short lived. For example: what happens if the CSC commands a stop while the axis is already stopped, or if it commands a point-to-point move to the current position? If you can figure out a simple, robust way to handle this, great. If not, feel free to ack it based on the current criteria: "the command is compatible with the current state and the parameters are in bounds". For the TRACK_VEL_CMD = 0x9031 command (which is received at 20 Hz) I suggest ack based on "the command is compatible with the current state and the parameters are in bounds". I don't think there is anything else you can wait for, and fast response is important.
            Hide
            Permalink
            ttsai Te-Wei Tsai added a comment -

            The TRACK_VEL_CMD will check the current state is Enabled state or not already. It also checks the values are in bound or not.

            Show
            ttsai Te-Wei Tsai added a comment - The TRACK_VEL_CMD will check the current state is Enabled state or not already. It also checks the values are in bound or not.
            Hide
            Permalink
            ttsai Te-Wei Tsai added a comment -

            Please help to review the PR:
            https://github.com/lsst-ts/ts_rotator_controller/pull/30

            Thanks!

            Show
            ttsai Te-Wei Tsai added a comment - Please help to review the PR: https://github.com/lsst-ts/ts_rotator_controller/pull/30 Thanks!
            Hide
            Permalink
            rowen Russell Owen added a comment -

            Reviewed on github

            Show
            rowen Russell Owen added a comment - Reviewed on github

              People

              Assignee:
              ttsai Te-Wei Tsai
              Reporter:
              ttsai Te-Wei Tsai
              Reviewers:
              Russell Owen
              Watchers:
              Russell Owen, Te-Wei Tsai
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Start date:
                End date:

                  Jenkins

                  No builds found.