Re: Draft requirements document for enhanced EPICS motor support

[Torsten Bögershausen <torsten.bogershausen@esss.se>]

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