Experimental Physics and
Industrial Control System

Hej all,

these are some of the itches we encountered:
- some of the motor record fields are not available in driver:
  e.g. MRES, EGU
  Should a new design give the driver access to all the fields in motor record ?

- the REP/RMP are double, rounded to integer and converted to double again

- No asyn TCP motor simulator (I have one, needs to be put on a public Git)

- Unclear when syncTargetPosition() is needed:
  The first time after we have a TCP connection, or each time after reconnect ?

- Alarm handling:
  It seems that we only use MAJOR_ALARM, is there a need for MINOR_ALARM ?
  (Modern controllers can produce 5..50 "health status values",
   like max current needed to do a motion, or an over current protection
   integration current over time)

- Code base
  Would it be OK for APS if we convert the motor or the aps subversion repo

  (Nice logo BTW)

- Thanks for the nice discussions





On 28/05/15 12:30, Mark Clift 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 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: [email protected] <mailto:[email protected]>

References:

RE: Draft requirements document for enhanced EPICS motor support Mark Clift

Navigate by Date:

Prev: RE: Motor R6-9 build issues on Windows Mark Rivers

Next: MAXv controller limits Phil Brown

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 Mark Clift

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