Axes which lose communication with their encoder do not properly enter an error state and remain there until reset. The FB drive block looks for a rising edge on the reset function which can occur if someone holds down the reset button and the error goes away for a cycle.

Also there is no way to clear errors from EPICS. This is a big operational problem.

Current Behavior

Currently MR2L3 and MR1L4 have state movers implemented for motion control, but rely on fast faulting coating protection function blocks.

Expected Behavior

They should use state movers with PMPS

Context / environment

Steps to Reproduce (for bugs)

Suggested Solution

Need to make the deadbands persistent values in the PLC to make the power cycle process more automated.

Symptoms include: having to reissue your last command to the pitch, slightly different to get it to take.

When the pitch gets near the stepper motor transition point it cuts the stepper enable which causes an error. This error causes the next pitch setpoint requiring the stepper to be ignored.

This is not good practice for two reasons:

1. These expire weekly
2. We shouldn't be on a trial license

Gantry Difference PVs are reporting non-sensical values. This is most likely a discrepancy between floating point types.

The stepper motors do not automatically reset after a power outage. A simple script to attempt a reset of the system would aid recovery.

Use a running calculation of the noise floor on the pitch axes to set the tolerance for move done.

Clearly these fields are not implemented to the description on the motor record docs:
https://epics.anl.gov/bcda/synApps/motor/R6-10/motorRecord.html#Fields_status

needs to be fixed for all axes.

Gantry axes do not include smooth mover functionality. Not a big deal, but these axes are slow, could be really annoying if they don't have a stop or smooth mover.

Once recovered, the system may recouple with excess gantry error. A script to automatically decouple and zero the gantry error would be helpful.