32-bit limitation on raw motor positions

[kmpeters]

The RRBV, REP, and RMP are currently limited to 32 bits:

motor/motorApp/MotorSrc/motorRecord.dbd

Lines 578 to 589 in 302d4d6

	field(RRBV,DBF_LONG) {
	prompt("Raw Readback Value")
	special(SPC_NOMOD)
	}
	field(RMP,DBF_LONG) {
	prompt("Raw Motor Position")
	special(SPC_NOMOD)
	}
	field(REP,DBF_LONG) {
	prompt("Raw Encoder Position")
	special(SPC_NOMOD)
	}

Changing the fields from DBF_LONG to DBF_INT64 will break compability with EPICS base 3.15. Higher-resolution encoders are going to be increasingly common.

[tboegi]

I stumbled accross the same problem while working with a piezo stage.
My feeling is that we could add additionally fields in double.
This is what the existing model 3 driver already support, so that
changes in the existing driver(s) are not needed.
And a double can hold 48 raw bits.

Something like FRBV, FRMP, FREP.
What do you guys think ?
@kmpeters @mp49 @MarkRivers

[MarkRivers]

I would be interested to know what would break if RRBV, etc. were changed to double and the motor record modified accordingly. It could still treat them as integers, but the number of effective bits would be 52 rather than 32. Would that affect drivers?

[kmpeters]

I stumbled accross the same problem while working with a piezo stage. My feeling is that we could add additionally fields in double. This is what the existing model 3 driver already support, so that changes in the existing driver(s) are not needed. And a double can hold 48 raw bits.

Something like FRBV, FRMP, FREP. What do you guys think ? @kmpeters @mp49 @MarkRivers

I don't think adding extra asyn parameters & records solves the problem. The motor record thinks the motor is moving in the wrong direction when the raw position rolls over when it hits 32 bits.

The workaround we've used for encoders higher than 32-bits is to convert the raw encoder reading into motor units and use it in the RDBL input of the motor with URIP=Yes.

[tboegi]

@MarkRivers Changing RRBV, REP and RMP into double does not give any compilation warnings for
all motor modules.
However, I didn't change devMotorAsyn.c to utilize the extra bits available in the motorRecord.

All in all, the RDBL solution seems a good way forward to me, thanks @kmpeters