When a database wants to use ACCS from the start, when the record is loaded
into the IOC, the init_record() function needs to look at it.
The new way is to set ACCS != 0.0 and ACCL == 0.0 and then ACCS takes over.
The compatible (call it old ?) way is to have ACCS == 0.0, and then ACCL
is used.
The problem:
When a user changes the velocity by writing to the VELO field,
but forgets to write to the ACCL field, the acceleration will
change and may be too high.
(Note: Many users are not aware of this side-effect).
Solution:
Introduce a field called ACCS, "Acceleration in seconds^2".
Once the field is written, the ACCL field is updated and the
acceleration is "locked".
It is locked for changes of VELO.
It can be be unlocked by writing to ACCL.
If the acceleration is locked (or not) is stored in the field ACCU,
which can be either "motorACCSused_Accl" or "motorACCSused_Accs".
And in this sense ACCU is not a lock, but just keeps track which
of the accelation fields ACCL or ACCS has been updated last, and
should be used in the next movement.
In any case an update to ACCS updated ACCL and the other way around.
Thanks to Mark Rivers for this nice idea.
1. Changed init function arguments in model-1 drivers to int
2. Simplified the init function logic related to "after"
3. Cast the pointer to the init function as DEVSUPFUN in the motor_dset structure
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
like this:
../devOmsPC68.cc:74:1: error: invalid conversion from ‘long int
(*)(int)’ to ‘DEVSUPFUN {aka long int (*)(void*)}’ [-fpermissive]
};
and this:
./devPmac.cc:66: error: invalid conversion from 'long int (*)(int)' to
'long int (*)(void*)'
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.
- It was using the value of mr->[link]->value.constantStr and mr->[link]->value.pv_link.pvname without checking the link types.
This was incorrect, and led to errors because constantStr no longer has a defined value if the link type is not CONSTANT.
Changed so that it only accesses these union fields if the link is the correct type.
- It did not check if pv_link.pvname was NULL before calling CA functions, though now that we check the link type perhaps this cannot occur.
- It did not lock the motor record before accessing the fields.
- Added Debug calls to show the link types and values.
Don't set "stop" field true if driver returns RA_PROBLEM true
Partially reverts commit 303a9208e3
Fixes issue #100:
> There have been multiple problems caused by the motor record sending a stop when the problem bit is set.
>
> One problem is discussed here:
> https://epics.anl.gov/tech-talk/2018/msg01338.php
>
> The commit that introduced the stop is 303a920. I vaguely recall the change being a workaround for less-than-idea behavior of a motor controller, but neither @rsluiter nor I remember which controller that was.
>
> Motor drivers should be modified to send the stop command when the condition that triggers the setting of the problem bit is detected, if needed.
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.
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.
Torsten Bögershausen