Experimental Physics and
Industrial Control System

Torsten Bögershausen <[email protected]> · Thu, 4 Jun 2015 10:57:00 +0200

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System