Status: To Do
Fix Version/s: None
Sprint:TSSW Sprint - Oct 11 - Oct 25, TSSW Sprint - Oct 25 - Nov 08, TSSW Sprint - Nov 08 - Nov 22, TSSW Sprint - Nov 22 - Dec 06, TSSW Sprint - Dec 06 - Dec 20, TSSW Sprint - Dec 20 - Jan 03, TSSW Sprint - Jan 03 - Jan 17, TSSW Sprint - Jan 17 - Jan 31, TSSW Sprint - Jan 31 - Feb 14, TSSW Sprint - Feb 14 - Feb 28, TSSW Sprint - Feb 28 - Mar 14, TSSW Sprint - Mar 14 - Mar 28, TSSW Sprint - Mar 28 - Apr 11, TSSW Sprint - Apr 11 - Apr 25, TSSW Sprint - Apr 25 - May 09, TSSW Sprint - May 09 - May 23, TSSW Sprint - May 23 - Jun 06, TSSW Sprint - Jun 6 - Jun 20, TSSW Sprint - Jun 20 - Jul 04, TSSW Sprint - Jul 04 - Jul 18, TSSW Sprint - Jul 18 - Aug 01, TSSW Sprint - Aug 01 - Aug 15, TSSW Sprint - Aug 15 - Aug 29, TSSW Sprint - Aug 29 - Sep 12, TSSW Sprint - Sep 12 - Sep 26, TSSW Sprint - Sep 26 - Oct 10, TSSW Sprint - Oct 10 - Oct 24
Team:Telescope and Site
When characterizing the limit switches for the following error between the CCW and the rotator neither of the two components stopped when reaching a following error 2 deg independent of the moving direction.
The test setup was:
- the speed limit of the CCW was manual set to a maximum of 2.6 deg/s
- the speed limit of the rotator was the nominal 3.5deg/s
- both components were at 10 deg (-10deg)
- the CCW following mode was enabled
- the commanded position was -10 deg (10deg)
When sending the move command both components start to move in the same direction. Because of the slower velocity of the CCW, the difference in position grows and the rotator hits the limit switch.
But: Both components should have stopped at a (configurable) software limit. This stop happens ideally in a controlled manner to protect the hardware but before the limit switch is reached.
Tiago Ribeiro We might have been using the EUI but I don't remember exactly. We were doing the tests by notebook but the rotator would run into issues trying to command it into enabled state. We might have switched to EUI to try and get both systems moving together but we ran out of time on the Summit.
The software limit is working. The mechanism is a controlled stop.
This means that the rotator does not reach the stop before the limits switches are reached.
There are two options to solve this:
- Change the deceleration value when the software limit is reached. This includes a certain time for communication.
- Create a new Substate (FastControlledStop?) parallel to the controlledStop substate. This is faster when implemented but implementation needs to be done by Tekniker.
The second solution is considered at this moment.
After the discussion with Tekniker today, the stopping state in trajectory is based on the maximum value of jerk. This means we might have two different maximum values of acceleration and jerk for the emergency stopping process.
After the discussion with Holger Drass, we will wait until the Tekniker delivers the code to verify this ticket again.
Austin Roberts, how were you commanding the rotator during these tests? At
08/26/2021 12:33:00 the CSC reported that the controller was no longer commendable by DDS. If you are executing these tests with the EUI, the CSC will loose command of the controller and won't be able to tell it to go to FAULT.
I don't see any move or track command in the EFD around the time of this test. The Rotator CSC was sending several errorCode events and trying to send the rotator to FAULT, but it can't if it doesn't have control.
I am not sure yet why the CCW went in the wrong direction.