commit 11229ed6e56, Fixed RVEL bug, made a change to be able
to set the .RVEL field in the motorRecord from a model 3 driver.
However, this mixes motorVelocity_,
which is a setpoint changed with every movement, with an actual value,
which changes while the motor is moving.
And goes to 0.0 when the motor has stopped.
Or stays at 0.0 when the motor refuse to start.
This may be caused by an interlock, limit switch, power off or others.
In short: Introduce a new asynParameter to store the value.
Compatiblity considarations:
Since the .RVEL field has never been working for an asynMotor,
we don't expect any.
If needed, code can be adopted at compile time, with something like this:
#ifdef motorActVelocityString
setDoubleParam(pC_->motorActVelocity_,
st_axis_status.fActVelocity);
#endif
* Add a global shutdown flag + epicsAtExit() handler
* Keep a separate ELLLIST of wakeup events
* Exit the infinite loop in motor_task if shutdown flag is set
Note: Argo (AI) suggested a broken version of this fix that needed to be
manually corrected.
Since commit 3b5c71c412 from May 2022 the change of MRES does
change the soft limits.
Technically speaking the introduced fields RHLM/RLLM keep their value.
The fields DHLM/DLLM HLM/LLM are updated.
Document this.
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.
Modern motion controller may have more advanced homing sequences
the what is specified in the motorRecord documentation.
However, many installations and implementations still use the
HOMF and HOMR fields to initiate such a homing sequence.
Make this more clear.
The CNEN field has been developed with motion controllers which can
switch between open- and closed-loop.
In modern controllers this is hard-coded inside the motion controller,
or to be more exact, sometimes the configuration of ths controller.
In other words, the CNEN field has been used to enable or disable the
motor.
Make this different usage and functionality more clear.
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.