RE: Draft requirements document for enhanced EPICS motor support

[Mark Rivers <rivers@cars.uchicago.edu>]

Hi Mark,

> Also, profile move modes relative, and absolute should be included too.

That is present, it is a parameter called "PROFILE_MOVE_MODE" and this enum:

enum ProfileMoveMode{
  PROFILE_MOVE_MODE_ABSOLUTE,
  PROFILE_MOVE_MODE_RELATIVE
};

It was added in SVN commit 17443, so it is present from R6-8-1 onwards.  The XPS profile move now implements it.

> Also, It is not the motor record that is the cause of some of the missing fields in model 3 (eg. DIR, POST),
> but rather the asyn interface that’s been defined for it.

I'm not sure that is true.  The problem is that the motor record does not call device support when those fields change.  So if I want to be sure that the values in the driver are up-to-date with the record how do I do that?  I can do it by defining additional records that have a CP link to those motor fields, and have those records push the value to the driver, but that is not clean.

Mark


________________________________
From: Mark Clift [Mark.Clift@synchrotron.org.au]
Sent: Thursday, May 28, 2015 5:30 AM
To: Mark Rivers; EPICS-motor-wg@github.com; mooney@aps.anl.gov; nick.rees@diamond.ac.uk; tech-talk@aps.anl.gov (tech-talk@aps.anl.gov)
Subject: RE: Draft requirements document for enhanced EPICS motor support

Dear All,

I too find the motor record interface has been a consistent element that we can build on, and that it has served well.  Recently, I added a motor driver for Galil products to the EPICS module support page, and this software has many of the features involved in this discussion.  Whilst developing this model 3 software, I found it was possible to implement most, if not all, of these high end features.

The issues I found with model 3 were:

-          Lack of output compare architecture

-          Lack of coordinate system selection architecture

-          Certain motor record parameters are needed in the driver, and they not present in the asyn interface to the motor record, or are not initialized early enough .  eg. DIR, PREM, POST, OFF

-          (Work-arounds exists for the above)

-          No clear defined way to implement pseudo motors, virtual motors, coordinate system motors. (eg. Slit width)

I did successfully implement: profile motion, coordinate system motors (eg. Slit width), output compare facility, coordinate system selection facility using the model 3.

I was not able to implement coordinate motion across multiple 8 axis controllers (eg. 16 motor profile move).  With a Delta Tau, this does look possible.

Given that the current model 3 seems capable, I am not certain the effort is justified yet.  With a thin layer motor record, the software above the record would not break.  Model 3 drivers below the state machine would also be easy to adapt, and would in most cases reduce driver code complexity.  Would the model 1 interface still be supported?  Also, It is not the motor record that is the cause of some of the missing fields in model 3 (eg. DIR, POST), but rather the asyn interface that’s been defined for it.

Using model 3, It’s possible to build pseudo motors, or coordinate system motors as I call them in the following way:

The coordinate system mechanism is built on top of the “Deferred moves” mechanism.  The usual <Controller>Axis.cpp was adapted for coordinate motors and became <Controller>CSAxis.cpp.  The CSAxis.cpp contains coordinate transform methods that use the scalc engine.  Using asynParamList, I added kinematics to the database in the following way:

8 forward equations per controller. Which means there is 1 forward equation per CS motor as 8 CS motors are supported per 8 axis controller (eg. I=(A+B)/2)
8 reverse equations per CS Motor that represent real motors A-H.  Which means 64 reverse equations per controller in total as there are 8 CS motors (eg. A=I-J/2)

The engineer can change the kinematics at runtime.  Above the CS motors is the motor record, so the CS motors look and feel real.  When the user moves a CS motor the system selects a free coordinate system, puts the controller in “deferred” moves mode, gives the motors the set points via transform, then releases deferred moves.  It happens all very fast, and you can tweak the CS back and forth using JOGF, JOGR, etc.   The coordinate system on the hardware is released at the end of the move and again becomes free.

I found the profile motion architecture in model 3, that has been defined based on the Newport XPS-C8, works well for the Galil controllers too.  This structure will also work for the Delta Tau PMAC2 (eg. GBLV).  The mutex locking in the profile execution code is a little painful, but that’s life when the system is running a lengthy profile, as the user may want to move independent motors.

Perhaps model 3 just needs a few minor additions, for output compare, and coordinate system selection for manual “deferred” moves ?  Also, I’d like to see profile execution mode added with the base choices being: linear, and pvt.  Linear and pvt would require different methods to actually run the profile.  Also, profile move modes relative, and absolute should be included too.

Best wishes,

Mark Clift.

Dr. Mark Clift
Senior Controls Engineer
Australian Synchrotron
800 Blackburn Road
Clayton 3168
Ph: +613 8540 4264
Fax: +613 8540 4200
Mail: Mark.Clift@Synchrotron.org.au<mailto:Mark.Clift@Synchrotron.org.au>