Motor: consider auto-correct of motor - encoder difference

[FreddieAkeroyd]

We are currently able to automatically correct any motor - encoder drift, but this is not enabled by default. If this difference gets too large it can lead to issues such as #5219 It is however useful to know what an accumulated drift has been.

Acceptance criteria

• Discussion with interested parties, specifically motion control group.
• add a new accumulated drift PV (autosaved and archived) that will record total drift, this would be zeroed only on a home maybe? the "current drift" pvs would remain as is.
• consider axes that should have auto-correction applied

discussed in planning 12/06/25 at ~00:29:00

[DominicOram]

Could do in conjunction with #5201

[FreddieAkeroyd]

We should consult with our customers (motion group, instrument scientists) as to what they would wish doing. We should lay out the scenarios, possible actions and any consequences. Once case to consider might be encoder failure, the motor may continue to move but would be reported "stalled" as the encoder would not move. If the motor position was corrected back to the (broken) encoder position, it would definitely be incorrect if the system was later put into open loop (it might be incorrect anyway as without an encoder you don't know for sure it actually moved to where you asked) and if the axis could not be homed potentially even more lost beam time. I am also aware that we do not necessarily want to alarm a user with "out of position" warnings, or lose beam time during the night when nobody is around if there is something that could be done. So we would likely need to do auto correction on a case by case basis and additionally only enable it on axes that can be "homed". Wording and form of warnings would need to be discussed with customers - doing a home to resync may not be convenient, so we may need to provide a "resync motor and encoder" button on the advanced motor screen.

[FreddieAkeroyd]

Under SECI limits were not enforced at the galil level, which meant no motor - encoder sync was required. I'm not sure if that totally avoided the issue of the broken encoder issue though, this depends on how SECI/labview moved motors between open and closed loop. Under ibex closed loop with retries mean that relative motor moves are done, so steps can get lost but position as per encoder is reached though the final motor step counter itself does not reflect the encoder position (hence the limits issue). Swapping to open loop after some missed steps would i feel give a position error unless this is allowed for separately.

[Tom-Willemsen]

Re-proposing as I this was the cause of a support issue/lost time on INTER.

From a discussion in the office with @FreddieAkeroyd , we feel that always resyncing is probably the better approach in the majority of cases (though there may be edge cases where it makes things harder, e.g. when swapping closed loop -> open loop after an encoder fails, then position will have been lost so will need to rehome/rescan).