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
Removed redundant postings of RMP and REP by moving them to device support's motor_update_values() and update_values().
Fix for LOAD_POS not posting RVAL.
Reversed order of issuing SET_VEL_BASE and SET_VELOCITY commands. Fixes MAXv command errors.
kpetersn
ext-muir_j