If I remember correctly, LBTO suffers from bad hardpoint limits readouts. Some filtering was either implemented, or there were discussions to not trigger fault the first time out-of-limits switch is hit, multiple hits were needed. LBTO uses mechanical proximity switches (as far as I can tell), and as LSST seems to employ proximity switches for HP out-of-limit detection, this note might not be relevant for LSST.

Mirror is being faulted whenever HP tries to travel past it's limit (limit switch is engaged and HP tries to travel beyond limit).

Thanks for the update

If we keep this situation we will get stuck and will not be able to recover. When we are on the telescope, if we fault and the mirror lands on the static supports they will compress enough to put the hardpoints outside of capture range. The hardpoint travel limit does not allow the hardpoint to change length enough to lock up the breakaway mechanism with negligible force. The travel limits of the hardpoints are intentionally limited for safety reasons. The hardpoint travel needs to be significantly less than the breakaway travel limit to prevent bottoming out of the breakaway limit, which would be catastrophic.

To recover we simply drive the hardpoints to their limits and lift the mirror. If we lift off without the breakaway locked up the system will simply and safely reposition the mirror.

I believe I understand the rationale for not doing that. There are reasons why we should.

We got stuck before, as the software tried to optimize HP forces to +- 200N. It silently timeouts being unable to move past limits, and we then spend hours looking for the cause (we are smarted now, so know what to look for,..).

With current changes (different compression & extension limits for raise/lower) we shall be safe and able to raise/lower at any mirror position. At least this change will fault the mirror right away, not wasting ~5 minutes just to timeout. Monitoring hitting limits has sense when the mirror is active (raised & operated by AOC), as optical corrections can drive hardpoints on limits. We don't have to fault the mirror, but at least record that in a log as a message (so we don't have to dig in telemetry).

Should we discuss how to proceed on Friday or sooner?

This was implemented and added. This detects failure (so the operator will not dwell for 5 minutes, waiting for a timeout, and then spending time figuring out why it timeouts). M1M3 shall pose capability to override any compression limits while rasing, as discussed in DM-33284.