Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: None
-
Labels:
-
Story Points:2
-
Epic Link:
-
Sprint:TSSW Sprint - Jan 18 - Feb 1, TSSW Sprint - Feb 1 - Feb 15
-
Team:Telescope and Site
-
Urgent?:No
Description
Implement a software safety system in the MTRotator CSC: if the error between the rotator and camera cable wrap gets larger than some specified amount, halt the rotator and put the system into a FAULT state. (This gives the camera cable wrap a chance to catch up, which makes it fairly easy to recover from this error).
This will rely on a new low-level rotator command that halts rotation and sends the low-level controller into the FAULT state. DM-28419
We would like to have in place by the time we add all the lines to the camera cable wrap and have to keep it in sync with the camera rotator. My understanding is that will occur sometime in February.
The desired limit is +/- 2.2 degrees. (I think this is also the specified limit for restarting the CCW if we pause it during an exposure. If so, one of these will have to change so we have some gap. But we'll worry about that if and when we decide we do want to pause the CCW during an exposure).
Attachments
Issue Links
Activity
| Description |
Implement a software safety system in the MTRotator CSC: if the error between the rotator and camera cable wrap gets larger than some specified amount, halt the rotator and put the system into a FAULT state. (This gives the camera cable wrap a chance to catch up, which makes it fairly easy to recover from this error).
This will rely on a new low-level rotator command that halts rotation and sends the low-level controller into the FAULT state. We would like to have in place by the time we add all the lines to the camera cable wrap and have to keep it in sync with the camera rotator. My understanding is that will occur sometime in February. |
Implement a software safety system in the MTRotator CSC: if the error between the rotator and camera cable wrap gets larger than some specified amount, halt the rotator and put the system into a FAULT state. (This gives the camera cable wrap a chance to catch up, which makes it fairly easy to recover from this error).
This will rely on a new low-level rotator command that halts rotation and sends the low-level controller into the FAULT state. We would like to have in place by the time we add all the lines to the camera cable wrap and have to keep it in sync with the camera rotator. My understanding is that will occur sometime in February. The desired limit is +/- 2.2 degrees. (I think this is also the specified limit for restarting the CCW if we pause it during an exposure. If so, one of these will have to change so we have some gap. But we'll worry about that if and when we decide we do want to pause the CCW during an exposure). |
| Status | To Do [ 10001 ] | In Progress [ 3 ] |
| Sprint | TSSW Sprint - Jan 18 - Feb 1 [ 1074 ] | TSSW Sprint - Jan 18 - Feb 1, TSSW Sprint - Feb 1 - Feb 15 [ 1074, 1076 ] |
| Reviewers | Te-Wei Tsai [ ttsai ] | |
| Status | In Progress [ 3 ] | In Review [ 10004 ] |
The update looks good to me. Thanks!
| Status | In Review [ 10004 ] | Reviewed [ 10101 ] |
Te-Wei Tsai's review of ts_mtrotator (no comments on ts_xml):
[rotator_csc.py]
1. Is it possible that does not put a "try loop" into another "try loop" to improve the readability?
https://github.com/lsst-ts/ts_mtrotator/pull/35/files#diff-55eba02cfb8e15463c6f159c1338c3a937c2b5a94d00fa50625d6335cd35bf60R342-R357
[rotator_commander.py]
1. I noticed you changed the velocity to speed such as the following:
https://github.com/lsst-ts/ts_mtrotator/pull/35/files#diff-0cd527a84bd148fd208dde64caff158f7272e94b88c646f3215bfd083743b149R41
Where is the code to judge the direction of speed? simactuators.RampGenerator?
https://github.com/lsst-ts/ts_mtrotator/pull/35/files#diff-0cd527a84bd148fd208dde64caff158f7272e94b88c646f3215bfd083743b149R126-R131
[test_csc.py]
1. I guess you do not need this empty line:
https://github.com/lsst-ts/ts_mtrotator/pull/35/files#diff-e4738762d295f3c94e7b14c1261fcb1aaac1e753fbdaee4dfb0cad4c8d244730R144
2. until the CCW follo"w"ing loop is running:
https://github.com/lsst-ts/ts_mtrotator/pull/35/files#diff-e4738762d295f3c94e7b14c1261fcb1aaac1e753fbdaee4dfb0cad4c8d244730R147
Also the Jenkins job is failing.
Thank you for the helpful review. Here is my response:
[rotator_csc.py]
1. Good suggestion. I also renamed the method from fault to afault and added a doc string because this is asynchronous,
unlike the base class version (which has a synchronous fault method that is disabled).
[rotator_commander.py]
1. Yes: simactuators.RampGenerator determines the direction from the start and end positions and ignores the sign of the speed argument. I found the old method really clumsy and feel this is much more pleasant to use.
[test_csc.py]
1. You are probably right. Unfortunately I was not able to find the line you are referring to. Github did not highlight anything in the diff for test_csc.py when I followed your link.
I did add a few new blank lines before comments where I felt it enhanced readability. (Sorry if that goes in the wrong direction!).
2. Thanks. Fixed (and I looked for other instances of that typo).
Jenkins job failing: Good catch. Turns out Jenkins wasn't building the MTMount IDL file. Fixed.
Merged both branches to develop.
I also tagged ts_mtrotator as v0.12.0.beta.1 but will hold off merging to master until we can validate this with the real rotator. That should happen in roughly a week, after rewiring the rotator limit switches.
| Resolution | Done [ 10000 ] | |
| Status | Reviewed [ 10101 ] | Done [ 10002 ] |
After discussion with Te-Wei Tsai and Tiago Ribeiro I also added a new "fault" command to the CSC, in order to simplify testing of the low-level controller's fault command.
Pull requests: