The following lead to an endless loop:
- move the motor by writing to the .VAL field
- while moving, home the motor using the HOMF field
- while still homing, write a different value to the VAL field.
The problem is that for "pmr->val != pmr->lval" the motorRecord is send
into do_work() and a new HOME is started.
Solution:
Reset the HOMF and HOMR buttons.
commit 24a53e660e,
"motorRecord: Reset UEIP to No if no encoder is present"
Seems to have introduced a typo:
When ueip is reset to false, because there is no encoder,
then db_post_events(ueip) should be called, not urip.
Fix the situation when MRES < 0 and either the softlimits
are changed (and RHLM and RLLM are garbled) or when
MRES itself is negative and changed, so that DHLM and DLLM
needed to be updated from the constant RHLM/RLLM.
Based on the update of DHLM/DLLM HLM/LLM will be updated as well.
The current implementation around RHLM/RLLM did not consider
MRES < 0 at all. And even if this configuration is not often
used, it is still supported.
Beside that we want to avoid RHLM=-40 RLLM=50 when it should be
the other way around
The function accEGUfromVelo() returns acceleration in EGU,
but we need it expressed in steps.
Thanks to Kevin Peterson for noticing.
Correct this and divide by fabs(pmr->mres).
And while there, correct a typo in a comment
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>
When the motorRecord is initialized, init_record() is called.
For asynMotors init_record() calls init_controller() in devMotorAsyn.c
From here, the encoder ratio is send to the driver.
After doing that, the code "locks" the execution waiting for a callback
to call epicsEventSignal(pPvt->initEvent) which "unlocks" the code.
As Mark Clift points out, this code can be simplified and the initEvent
can be removed.
Mark Rivers suggested to use the asynFloat64SyncIO interface,
which locks the asyn port when calling the driver.
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
zimoch
Torsten Bögershausen
zamofing_t