On 02/06/15 15:49, Kevin Peterson wrote:
On 5/26/15 11:28 AM, Mooney, Tim M. wrote:
I started to edit the requirements document, but the premise seems
to be that we would like to get rid of the motor record if only we
could. I don't feel this way. I think it's a very valuable
implementation of the behavior needed for nearly all the motors on
APS beamlines. An important but small number of motors need a
better model to do complicated motions, and I'd like to focus my
effort on those needs, without also pursuing the goal of
reimplementing stuff that works.
One of the reasons I have thought about rewriting or replacing the motor
record in the past is that the motor record was not designed to handle
multiple fields changing simultaneously. Here is an example:
1. Change a motor's VAL field using an NPP link from another record in
the IOC
2. Set the motor's STOP field to one using an NPP link from another
record in the IOC
3. Process the record once by writing 1 to the PROC field; the motor
record sends the stop command to the controller and resets the STOP field.
4. Process the record a second time; this moves the motor to the VAL
specified in step #1.
Note: The behavior is the same when PP links are used to write to a
motor record that is disabled (DISA=DISV,DISP=1).
This failure to handle multiple field changes has resulted in motors
moving when users were trying to redefine a motor's position.
Just to ease my understanding:
Q1: Is there a risk for a race condition ?
Q2: What is the desired behavior ?
When should the motor actually do the movement ?
Writing to which record field should trigger it?
Q3: Is this what the "Deferred moves for asyn motors" ?
http://aps.anl.gov/bcda/synApps/motor/R6-8/motor_release.html
Can it be used, in theory ?
In practice, if not why not ?
Q4: Can the SPMG field be used ?
If not, why not ?
And that leads to question 5:
Q5: Should this kind of "business logic" be part of the motor record ?
Should it be moved out of the motor record and become a support record ?
Or can e.g. a calc record be used ?
calcout ?
seq ?
Any other ideas ?
And of course Q6:
Q6: Does it make sense to make a little application/Db, which illustrates
the problem ?
I am working on a test framework based on python/pyEpics, and we can
add these kind of use-cases, most probably later.
Another reason I've wanted to enhance the motor record is that I've
found it to be the obstacle when trying to implement multi-axis
coordinate transforms of arbitrary motor axes using motors with
soft-channel device support in such a way that all the target positions
stay synchronized. I can elaborate on that if falls within the scope of
this discussion.
I think it does.
Kevin
- References:
- Draft requirements document for enhanced EPICS motor support Mark Rivers
- RE: Draft requirements document for enhanced EPICS motor support Mooney, Tim M.
- Re: Draft requirements document for enhanced EPICS motor support Kevin Peterson
- Navigate by Date:
- Prev:
Re: Using devIocStats under dynamic epics build. Alireza Panna
- Next:
RE: Draft requirements document for enhanced EPICS motor support Mark Rivers
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Draft requirements document for enhanced EPICS motor support Kevin Peterson
- Next:
RE: Draft requirements document for enhanced EPICS motor support Mooney, Tim M.
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
<2015>
2016
2017
2018
2019
2020
2021
2022
2023
2024
|