Smoothing motor readback
Several Galil systems use analogue feedback as the encoder, this is effectively an absolute encoder (so no need to rehome etc) but the readback can be noisy and this has caused issues in the past with setpoints looking like they are drifting. The WISH instrument is an example.
We did look at smoothing the values within an EPICS db using the compress record etc. and linking this to an alternative motor readback as per old notes, but it turned out the jaws were so noisy it swamped the Galil and we had to add smoothing there.
The data is smoothed using the same algorithm available in an epics analogue input (ai) record i.e. a first-order infinite impulse response (IIR) digital filter.
New_Val = Old_VAL * SMOO + (1 - SMOO) * New_Data
So SMOO == 0
is no smoothing. During a move the un-smoothed encoder position is returned by the galil IOC to the motor record, but once motion has stopped the smoothing algorithm is activated to smooth the the data. For the system to work it needs to:
be setup to retry moves (which is our default)
have a readback delay set (something like 2 seconds) The readback delay is important as this is how long the motor record waits (settle time) after a move has finished before it uses the position for the next task (retry in our case). So the readback delay is how much time we are averaging the encoder readback of the stationary motor for before we decide on any correction/retry to get to the requested setpoint.
have an non-zero smoothing factor.
To set this up for MTR0105
on WISH for example you would:
Set max retries (MTR0105.RTRY) to > 0 (typically 10)
Set
readback delay
(MTR0105.DLY) to a reasonable averaging period (e.g. 2 seconds)Set encoder smoothing factor MTR0105_ENC_SMOO_SP to > 0 e.g. 0.5 You may need to experiment a bit with delay and smoothing. Bear in mind that these are autosaved at 30 second intervals, so don’t restart IOC too soon after a change or you will lose them.
Old approach
Note
This is the old proposed way and not currently used, but some of its implementation is in place
To solve this issue, the readbacks can be smoothed using an EPICS compress record and this fed into the motor record by using its optional readback link functionality. So the motor record internally sets values as usual, but using a different route for readback. A few notes on the system:
the motor record
REP
field is monitored via the_EPOS_CALC
PV, stored in a circular buffer in a compress record and then a configurable number are averaged to provide anEPOS_AV
PV. The linking is done via a channel access monitor, so assumes that the readback is noisy and that the noisy rate is sufficient to generate a good number of values to average. It would be possible to explicitly scan this record if you wished to average a less noisy signal.when the motor record is using the readback link, it is in “no encoder” mode i.e. it thinks it is in open loop. The only visible effect of this is that on startup it didn’t sync the last setpoint to the current readback, this has been resolved by forcing a delayed write to the motor record SYNC field after ioc startup (see
_EPOS_INIT
and_EPOS_SYNC
PVs). This needs to be delayed so channel access and other things have started.a readback delay needs to be set on the motor record, this is because the compress record averaged values will be a bit biased by the motion that has just occurred otherwise and so any retry calculation distance will be incorrect.
To set this up for MTR0105
on WISH for example you would:
have a non-zero
max retries
count - default is 10set a
readback delay
, currently using 5 secondsset
readback resolution
to 1 (we have handled this in the_EPOS_CALC
record)set a
readback link
value - for MTR0105 on WISH this isIN:WISH:MOT:MTR0105:EPOS_AV CP MS
set
use encoder
tono
set
use readback
toyes
Setting use encoder
to no
before enabling readback is probably a better sequence of operations, but not crucial. If you set readback to yes it automatically sets encoder to no, but i had a case when it seemed to get a bit confused. If it does make sure values are correct and then just restart ioc and autosave will apply them correctly. Bear in mind that these are settings and so autosave at 30 second intervals, so don’t restart too soon after a change