OMS: Synchronize motor position with encoder position before every move

[ltjax]

Our motor position was often not synchronized with the encoder position, resulting in very erratic behavior once the encoder was used. This fixed it.

I'm not entirely sure this was the best place to apply this synchronization - if there's a better place, please do tell!

[tboegi]

The lines
"Version: $Revision$" do not belong to this change, do they?

[ltjax]

You're right. I removed that.

[kmpeters]

Hard-coding the encoderRatio to 1 causes problems for any application where the drive resolution is different than the encoder resolution.

Can you elaborate on the configuration of the motor records and the very erratic behavior you saw without the fix? It sounds like there may be a bug in the motor record itself when UEIP=Yes.

[ltjax]

It's not hard-coded, just initialized as 1. The setEncoderRatio override sets it correctly. I just added that because I needed the encoder ratio to convert from encoder step position to motor position. It's not 1 in our case.

Well, very erratic was basically: does not make sense at all. You'd tweak it forward, and sometimes it would go forwards, but not stop until it ran into the stop switch, or sometimes it would go backwards for seemingly random amounts. Debugging revealed that the motor and encoder positions where not synced correctly. What exactly causes that, I do not know. I can tell you, that encoderPosition = motorPosition * encoderRatio did not hold in the hardware and this fixed it. So basically, the encoder's and motor's 0 position seems to be somewhere else.

I asked around with people who are driving this hardware with Tango instead of EPICS, and they basically had to do the same to get the motor/encoder pair to work correctly.

[mp49]

The motor and encoder positions on the controller can get out of sync for all kinds of reasons, and I've seen similar issues if UEIP=Yes. However, if RTRY is non-zero then every move will be relative to the encoder readback, and so these problems can be avoided that way.

Syncing the motor to the encoder position in the driver seems like the right solution, and I know of other drivers that do this (but only when UEIP=Yes).

[kmpeters]

It's not hard-coded, just initialized as 1. The setEncoderRatio override sets it correctly. I just added that because I needed the encoder ratio to convert from encoder step position to motor position. It's not 1 in our case.

@ltjax I didn't notice the setEncoderRatio override before making my previous comment. Thanks for pointing it out.

The motor and encoder positions on the controller can get out of sync for all kinds of reasons, and I've seen similar issues if UEIP=Yes. However, if RTRY is non-zero then every move will be relative to the encoder readback, and so these problems can be avoided that way.

@mp49 It seems like the motor record should also move relative to the encoder readback when UEIP=Yes and RTRY is zero, but that may not completely eliminate the need for this fix.