EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Draft requirements document for enhanced EPICS motor support
From: Mark Rivers <[email protected]>
To: Mark Clift <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected] ([email protected])" <[email protected]>
Date: Thu, 4 Jun 2015 12:21:00 +0000
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 [[email protected]]
Sent: Thursday, May 28, 2015 5:30 AM
To: Mark Rivers; [email protected]; [email protected]; [email protected]; [email protected] ([email protected])
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: [email protected]<mailto:[email protected]>


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

Navigate by Date:
Prev: RE: Draft requirements document for enhanced EPICS motor support Mark Rivers
Next: aravisGigE areaDetector with Basler camera Specht, Eliot D.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Draft requirements document for enhanced EPICS motor support Torsten Bögershausen
Next: FW: Draft requirements document for enhanced EPICS motor support Mark Clift
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  <20152016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Dec 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·