Noisy motor encoder causing phantom moves for Kohzu-style Monos

[mdwyman]

From 8ID:

The kohzu sequence program that lets the beam lines drive in the energy space needs some fixes. I believe it was written with open loop stages in mind. With the new high res encoder monos, the counts are always fluctuating and this makes the kohzu energy also fluctuate showing it always in a Moving state. This prevents efficient scanning and setting energy value as it is always overridden by the changing value.

Was able to replicate the behavior with a simulated motor used as the theta motor with the Kohzu Mono setup:

Review of the kohzu stage program (kohzuCtl.st), it looks like updates to the theta motor readback is copied back to AO PV for the theta motor in the optics module's kohzu mono support. When this PV is updated, the Moving state is entered. In normal/actual moves, the AO PV is updated at the end of the move.

In a deeper sense, the issue at 8ID seems to stem from noisy encoder (at least at the less significant bits) updating the motor's readback when just sitting. One (temporary) solution is to use the Readback link for the readback position have it get its value from a calcout that "smooths" the encoder reading. This has been implemented at 8ID with the calc looking like:

[mdwyman]

Is it really necessary to update the control value after an external move? Does appear to be necessary for how tweaks are currently handled.

[mdwyman]

Also looks like the control values (E, lambda, and theta) are "pvput" to in many places in the state program. Each set the mono's busy to "Moving", so it may require a re-vamping of the whole state program to handle noisy encoders.

It is possible to put together purely EPICS support (no sequencer programming) for the mono. At S25, the mono support is purely EPICS DB (https://git.aps.anl.gov/25id/25iddcm), but it doesn't have the limit checking that the optics module's kohzu mono support (among other things perhaps). The S25 support also wasn't meant to be flexible -- it was setup for the monos at 25 and may not be easily extensible for other mono geometries.

[prjemian]

Is a deadband included for encoder readbacks?

[mdwyman]

Is a deadband included for encoder readbacks?

Do you mean in the current optics mono support? The S25 mono support? The motor record?

In a sense, MRES acts like a deadband: If the noise level (1/C in the readback calc) is set to near or larger than MRES (0.001), I would see this effect. If the noise level stayed (C = 10000, so 1e-4 for the noise level) below MRES, the system appeared stable (i.e. the motor readback doesn't update).

From the motor record/ACS support, I don't believe there's an explicit encoder deadband. Simliar to the readback link solution, one could also configure the motor controller to "drop" a number of the less significant bits and get the same effect.

[prjemian]

Whatever it takes to help the state notation language code to stop reacting to the encoder while it continues to update while in position.