A negative BDST was correctly applied to negative direction moves
if moves are absolute. When retries are enabled all moves become
relative and backlash was not applied correctly for negative direction
moves.
We can't compile motor against this commit of EPICS base:
commit 0f428ea3346d89719b03a6419319c85afb0fee13
Author: Michael Davidsaver <mdavidsaver@gmail.com>
Date: Thu Apr 1 10:57:19 2021 -0700
use DBCORE_API
Solution: Include <shareLib.h>
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.
The 2nd and 3rd parameter in send_mess() can and should
be a 'const char *' instead of just 'char *'.
Modern compilers complain here, so that the signature now
gets the const.
Update drivers from the following list to use the new send_mess():
modules/motorAcs
modules/motorAcsTech80
modules/motorAerotech
modules/motorFaulhaber
modules/motorIms
modules/motorKohzu
modules/motorMclennan
modules/motorMicos
modules/motorMicroMo
modules/motorNewFocus
modules/motorNewport
modules/motorOms
modules/motorOriel
modules/motorPI
modules/motorParker
modules/motorPiJena
modules/motorSmartMotor
modules/motorThorLabs
And while there, fix one more "const char *" in motordrvCom.cc
This is from Matthew Pearson, pearsonmr@ornl.gov
A number of users and staff have requested that the motor record have a
setpoint deadband field (eg. SPDB), which prevents any motion from
happening if the readback position is within SPDB.
Without a SPDB we have issues with motors moving unnecessarily.
For example, if the RBV is 0.001 and we set VAL to 0.0, if we have a
non-zero backlash correction then the motor will move unnecessarily
to take out backlash.
Even without backlash correction we often enable and disable the
drive amplifier for no good reason.
Currently the effective setpoint deadband is equal to MRES,
but this is often too small to be an effective setpoint deadband.
The new SPDB field would default to 0.0
The new code hooks into do_work():
When the new setpoint is within DPDB, set too_small and don't move.
The new code does not use snipptes like "abs(npos - rpos)", these
already produce warnings on 64 bit sytems.
abs() is declared to work on int, but we feed long values.
Simply compare the coordinates in engineering units.
The asyn module make the constructor
asynPortDriver::asynPortDriver(const char *portNameIn, int maxAddrIn,
int paramTableSize, int interfaceMask, int interruptMask,
int asynFlags, int autoConnect, int priority, int stackSize)
obsolete in R4.32.0, the more modern version should be used, which does
not have the parameter paramTableSize.
Using a modern version of asyn for the motor gives a compiler warning.
As I don't like compiler warnings, add a #ifdef construct to suppress it
for asyn > R4.32, and still allow to compile agains asyn >= R4.32
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.
the driver's responsiblity to stop a motor if the condition that results
in the RA_PROBLEM bit being set doesn't result in the motor
automatically stopping.
This partially reverts commit 303a9208e3
motorRecord.cc: Jogging against to LVIO in LVIO
This change resets the JOGF/JOGR fields to zero when a limit violation occurs, rather than when the JOGF/JOGR fields get reset to zero by the user.
When jogging has stopped because the motor is close to a softlimit,
the record seems to be locked up when the same jog button is pressed again.
The user must release the jog button, before doing any other action.
STOP doesn't help, neither does jog into the opposite direction work.
Solution:
Clear the JOGF and JOGR button in the record.
Record recognizes motor stop while jogging.
Text from the pull request:
'The following situation came up while debugging soft limits in a
motion controller which had different values then the record.
The motor is at position 50mm (RBV=50), the low soft limit is 15 (LLM=15),
jogging velocity is 10 mm/sec (JVEL=10).
The motion controller has an internal soft limit which is 35 mm, which
we want to test.
Set JOGR to 1, the motor will move backwards.
(Side note: it would be stopped by the record once it passed 25mm).
Before that, the motion controller stops the motor internally and reports DONE.
The state machine in the record is not prepared to handle this and JOGR stays 1.
The expected behavior is that JOGR returns to 0.
Because this is an unexpected stop, reset even pending home requests.
In other words: call clear_buttons(pmr)
Whether or not an alarm is raised may be another question.
The natural thing would be to set LVIO to 1, but we don't know why the controller
stopped the motion.
Unless we add a bit in MSTA like "RA_LVIO"...
But in any case this can and should go into a separate commit.'
The following situation came up while debugging soft limits in a
motion controller which had different values then the record.
The motor is at position 50mm (RBV=50), the low soft limit is 15 (LLM=15),
jogging velocity is 10 mm/sec (JVEL=10).
The motion controller has an internal soft limit which is 35 mm, which
we want to test.
Set JOGR to 1, the motor will move backwards.
(Side note: it would be stopped by the record once it passed 25mm).
Before that, the motion controller stops the motor internally and reports DONE.
The state machine in the record is not prepared to handle this and JOGR stays 1.
The expected behavior is that JOGR returns to 0.
Because this is an unexpected stop, reset even pending home requests.
In other words: call clear_buttons(pmr)
Whether or not an alarm is raised may be another question.
The natural thing would be to set LVIO to 1, but we don't know why the
controller stopped the motion.
Unless we add a bit in MSTA like "RA_LVIO"...
But in any case this can and should go into a separate commit.
Fix the problem that the record gets stuck when STOP is
pressed while the record is in MIP_DELAY (and the motor
is standing still, so that there is no record processing).
Currently the MIP_DELAY bits are set to 0, when a STOP is issued.
As the motor already hase stopped, the DMOV field never goes to 1.
There are 2 possible solutions here:
a) STOP wins:
pmr->dmov = FALSE;
MARK(M_DMOV);
b) DELAY wins
Send a STOP to the controller (just to be sure), but wait for the DELAY.
a) may cause probles later, whena new positionioning is done after the STOP
and a new DELAY is triggered.
As the old callback is still active, it may be executed before the new
callback. And the time will be too short.
For this reason go with b)
http://www.aps.anl.gov/epics/tech-talk/2015/msg01786.php
Freddie Akeroyd
ext-muir_j