Japan:
"While I was developing an EPICS application on the top of the motor
module, my application died for segmentation fault. The reason was my
mistake: I forgot to call XPSConfigAxis before I start to use that axis,
but it took time for me to find it out (e.g. compiled the motor module
and my application with debug option, running gdb, ...). So, I thought
it would be nice if an error message is shown in the console instead of
sudden death only with segmentation fault message, and the attached
patch does it."
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.
Modified drivers that expect unsigned encoder ratio parameters, as discussed in issue #82. This change preserves the behavior of the device support for the MM3000 and OMS controllers before pull request #84.
* Use APS links instead of github preview links until the
release contains the relevant documentation (motor.html)
* Changed one instance of 6-9 to 6-10 (motorRecord.html)
Kevin Peterson