- Software: BM
- AO: AV, JCG
- Software versions used:
- lbti-sxwfs: test.20220425.interrupted-offsets-and-bayside-timeouts
- Software version after test:
Test: verify that the WFS arbitrator reports errors on out-of-range bayside stage movements instead of waiting for a timeout.
Currently, if an out-of-range bayside movement is requested, the WFS arbitrator will wait until the position reported by the CopleyCtrl
process reaches the target (simplemotor.py:L241-L247
), which it never will, resulting in a timeout. If CopleyCtrl
reports an error during the movement, instead of catching the error, the WFS arbitrator will just wait for a timeout to expire, which can take up valuable telescope time.
) This change allows CopleyCtrl
to report error codes and messages to the WFS arbitrator using two RTDB variables, one for the error code, and one for the error message. If simplemotor.py receives a non-zero error code, it will stop waiting for the position to reach its destination and raise an exception with the message reported by CopleyCtrl
. I didn't change SimpleMotorCtrl
, which doesn't check for out-of-range motion but just clips the movement request into the range, but the change is backwards compatible.
I've tested the changes in a VM, making sure that both bayside_stage (CopleyCtrl
) and rerotator (a SimpleMotorCtrl
) both behave as expected for in-range and out-of-range motions. See this comment in the pull request
This can be tested daytime during open loop through the WFS hardware GUI.
- Perform in-range bayside stage movements to make sure they still work as expected.
- Perform some out-of-range bayside stage movements to see that a VALUE_OUT_OF_RANGE_ERROR is raised.
- Try requesting a bayside stage movement while another is still executing. This should raise a STAGE_BUSY_ERROR.
- Try moving any other motors and make sure they work as they did previously.
- Try moving any other motors out of range and make sure they work as they did previously.
- Everything worked as expected. We tried in-range bayside movements and they worked fine. Out-of-range bayside movements gave an error immediately. Out-of-range movements of the filterwheel (which uses SimpleMotorCtrl) worked as before, reporting that they moved to the target position, since there is no check for out-of-range movement.
- Should be clear for DEC checkout and then including in the next software release.
- 25 Apr 2022