Partly revert the following commit:
commit 3090983c31
Author: Ron Sluiter <rsluiter@users.noreply.github.com>
Date: Wed Jul 29 15:50:23 2015 +0000
Bug fix for target position (VAL/DVAL/RVAL) initialization error
when the motor record is configured to do retries.
And from the release notes:
6) Kevin Peterson discovered an initialization bug when the motor record is
configured to do retries. When configured to do retries, the motor
record issues incremental rather than absolute moves. If the motor
behaves badly (e.g., a piezo stiction motor) the controller's absolute
step count can be far from its' absolute readback position. The motor
record initialization logic that determines how the target positions
are initialized at boot-up was not taking into consideration whether
or not the motor record is configured to do retries, and therefore,
whether or not absolute or incremental moves were issued by the motor
record. With this release, if the motor record is configured to do
retries, then the controller's absolute position is ignored (because
the controller's absolute position was "corrupted" by retries) and the
autosave/restore position is used to set the controllers position.
Switching between retries on and off (relative vs. absolute moves)
between reboots will cause unpredictable results and is not covered
by this bug fix.
Files modified: motor_init_record_com() in MotorSrc/motordevCom.cc
init_controller() in MotorSrc/devMotorAsyn.c
Commit 3090983c improves the situation for setups where autosave is
used, and makes things worse when autosave is not used.
When autosave is not used and the motor is configured to do retries,
the the DVAL field is loaded into the controller regardless.
And because DVAL is 0.0 at startup, the controller position is lost.
The first issue report is found here:
"Problem with R6-10 issue 6 fix - controller position can be lost on reboot"
https://github.com/epics-modules/motor/issues/85
And the we have another issue report here:
"IOC zeroes encoder on startup"
https://github.com/motorapp/Galil-3-0/issues/13
A possible way forward is discussed here:
"Add a field to the motor record to allow always restoring the
autosaved position"
https://github.com/epics-modules/motor/issues/151
This commit adds the "RSTM" field:
- 0 Disables restoring the autosaved position
- 1 Always restores the autosaved position
- 2 Uses the same logic as motorRecord 6.9 (or older)
- 3 Uses the same logic as motorRecord 6.10
This numbering maps 0 and 1 somewhat to false/true, uses 2/3 for
special handlings and leaves room for more choices.
E.g. "use the encoder value, if valid, fall back to autosave if not.
Or "use the URIP/RDBL" if possible.
I am getting off-topic,
those improvements should be done in later commits anyway.
Refactor the changes for the deprecated RECSUP in later EPICS base
version, which need a typedef for struct rset.
Unite all common code and put it into a single include file.
Add motor_epics_inc.h.
Remove more compiler warnings when compiling against the base 7.0 branch.
Note:
Some of the model1/2 drivers still give a warning. As I can not test the
code, leave those files untouched.
get picked up as the initial motor position, val, dval, rbv, etc
Fix initialisation of motors on Linux with autosave (was trying to lock a
previously-destroyed mutex)
devMotorAsyn.c and drvMotorAsyn.c to use it
Added STATUS_* reason codes to get at individual bits of status
Fix SET_{LOW,HIGH}_LIMIT command when MRES negative
Removed motorAxisPrimitive, motorAxisSetLogParam
motorAxisSetLog now takes a logParam parameter
drvMotorAsynConfigure takes an extra can_block parameter
Simulator create function only takes int parameters to avoid problems
passing double parameters from the vxWorks shell on PowerPC arch
Functional changes:
Order of drvMotorAsyn interrupt callbacks has been changed to pass back
Float64 interrupts (typically position, etc.) before Int32 interrupts
(typically status), so that a move reaches its desired position before
it is signalled as complete. This is not a complete solution.
More parameter checking, particularly of axis number
Torsten Bögershausen