Experimental Physics and
Industrial Control System

"Pearson, Matthew R." <[email protected]> · Thu, 28 May 2015 14:11:40 +0000

Hi,

Does anyone use the motor record PREM/POST fields for anything other than enabling or disabling an amplifier? That seems to be the most common way to use these fields. 

I recently added support for enabling/disabling the axis amplifier in the Asyn model 3 base class (which uses the setClosedLoop function and configurable delays), although it might need to be improved. 

I also found a use case for adding a post move delay at the end of each driver move (not at the end of the motor record move, which is already catered for via the DLY field). This caters for settling time when doing backlash and retries via the motor record (essential for large heavy stages). 

Cheers,
Matt

Data Acquisition and Control Engineer
Spallation Neutron Source
Oak Ridge National Lab

On May 28, 2015, at 6:29 AM, Mark Clift <[email protected]> wrote:

> 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 controllers 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)
>  
> Up to 8 motors are allowed in a single CS motor.  A single CS motor may also contain both real, and other CS motors (done by substituting kinematics).
> 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.  The readback for a CS motor is treated the same as axis::poll with an additional coordinate transformation via scalc.  The motor record attached to the CS motor can then be used to define backlash, and other parameters.
>  
> 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 this area 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 and CS motors.  Also, I’d like to see profile execution mode added with the base choices being: linear, and pvt.  Similar to the profile move modes relative, and absolute, in that these are profile attributes.
>  
> Best wishes,
>  
> Mark Clift.
>  

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System