Remove the history of trajectory after issuing the stop command in the tracking. The Simulink model uses the LsstCmdSet object to get the time, position, and velocity of tracking target. If the user issues the stop command before the finish of slew, the rotator stops without the update of LsstCmdSet. This means if the user issues the trackStart command, the rotator will transition to the SlewingAndTracking sub-state and try to track the unfinished target based on LsstCmdSet.

In the following figure, there are two targets: (1) position=1.2 deg, velocity=0.01 deg/sec, and (2) position=3.0 deg, velocity=-0.01 deg/sec. The final track command is at time=6.05 second. Issue the stop command at time=7 second and trackStart command at time=9 second. We can see the rotator tries to finish the second target after it is back to the SlewingAndTracking sub-state.

To solve this problem, we need to update the LsstCmdSet object to set the position to be the rotator's position or position command, and the velocity to be 0 after the stop completes (Flags_stopComplete ==1.0) as the following:

There are four possible options to do this:
(1) Update the LsstCmdSet object in ts_rotator_controller once Flags_stopComplete==1.0.
(2) Let ts_rotator update the LsstCmdSet object by sending the new track command once Flags_stopComplete==1.0. However, we prefer to use the command acknowledgement to know the stop command is finished or not in a latter time.
(3) Add a reset command or something similar in ts_rotator and ts_rotator_controller to let the rotator controller updates the position and velocity of LsstCmdSet.
(4) Update the Simulink model to add a latch to determine when to use the new track command. This will add the complexity to the Simulink model because it is not designed in that way originally. It may not be easy to debug in a latter time. However, this will not affect the ts_rotator and ts_rotator_controller at all.

I do not prefer the option 1 because there will be multiple places to write the data into the global variable of LsstCmdSet. Originally, it is updated by ts_rotator only. Or more accurately, the ts_rotator issues the track command to update the LsstCmdSet in commanding.c in ts_rotator_controller. If the option 1 is chosen, I need to let the actuator.c to be able to update the LsstCmdSet object. Think more deeply, for the option 3, it is the same thing. The only benefit for option 3 is that the CSC user knows the LsstCmdSet is changed. But if the CSC user does not care about this, maybe the option 1, 2, or 4 is better. If we consider the coherence of code, maybe the option 1 or 4 is the best solution.