Redefining the position of a motor with an absolute encoder

[kmpeters]

There are some situations where it is necessary to disallow redefining the position of an axis with an absolute encoder.

This can be done at the driver level for model-3 motor drivers:

https://github.com/epics-motor/motorAcsMotion/commit/17a0aac6f39628635a1c890f2372e457d846c993

Should this be done at the motor record level instead?

[kmpeters]

@MarkRivers & @tboegi, do you have thoughts on this?

[tboegi]

@kmpeters My thoughts: The record itself does not know, if there is an absolute encoder - or not. The driver may know it - if it can ask the controller, if there is an absolute encoder.

For the TwinCAT case, there is a definition of a "homing procedure". And if it is 0, the motor can not be homed, because it has an absolute encoder. At the same time, we make the FOFF switch invisible in the CSS screen.

So in short: I do it on the driver level as well: https://github.com/EuropeanSpallationSource/m-epics-ethercatmc/blob/master/ethercatmcApp/src/ethercatmcAxis.cpp#L723--L734

[mp49]

For the Galil controller, I think it just ignores 'set position' commands for the encoder if there is an absolute encoder. I suspect setting the motor position is still allowed, but the Galil driver will automatically sync the motor to the encoder after a move so if we do try to set motor position it will immediately be set back to match the encoder. So for homing these axes we just set OFF (and we set FOFF=1). However, if the driver didn't auto-sync, we'd need to be able to set the motor position via a motor record SET=1.

[kmpeters]

One problem I see is that the motor record redefines the controller's position when the MRES is changed. This is welcome if the MRES is changing because the microstepping level of a stage is changing. It is NOT a welcome change if the EGU is being changed (from mm to um, for example). If the driver doesn't protect against setting the position and a user wants to work in different units, the redefining of the absolute encoder's position is very surprising.

[mp49]

When changing units it does seem like it would be useful to not automatically set the controller position. Although that's not specific to absolute encoders, right?

How would it work? Provide a new field that enables/disables 'set position'? Then if you want to change units, first disable that new field, then change MRES, then enable the new field again?

I know some axes or controllers and/or sites have a policy where the controller is always correct, and never want to set position from EPICS. So being able to disable that from the motor record may be useful.

[tboegi]

@mp49 and @kmpeters : Could someone be so kind and enlighten me and others, when and why MRES is changed at runtime ? Is it a user thing, we want micrometer instead of millimeter ? Or is it commissioning ?

[kmpeters]

Users at the APS have changed the MRES because they wanted to change the unit from millimeter to microns. We have also changed the MRES of motors when the number of mini/microsteps on a stepper motor driver are changed. I consider both of these to be normal reasons to change the MRES at runtime.

We have changed the MRES for XPS axes to increase the resolution, but this also requires changing the stepSize argument of XPSCreateAxis and restarting the IOC.

[tboegi]

Thanks for sharing the "we need to change MRES" use cases, @kmpeters Back to the controllers with absolute encoders. Does it make sense to "install" a "soft motor" on top of the "hard motor" that allows MRES to be changed e.g. from millimeter to micron ? And then we can leave the "hard motor" alone, not bothering it with any "load position" calls. Especially as we can fiddle e.g. the limit switches through the new MINP field: https://github.com/epics-modules/motor/pull/211 Any thougths ?

[kmpeters]

I would not want to add soft motors to a setup unless it was absolutely necessary and there was no other way to achieve the desired effect. Soft motors come with their own quirks and I would expect the addition of the soft motor to cause more problems than it solves.