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  <20112012  2013  2014  2015  2016  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  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: MAXv question
From: "Mark Rivers" <[email protected]>
To: "Dirk Zimoch" <[email protected]>
Cc: EPICS <[email protected]>
Date: Fri, 1 Apr 2011 09:47:31 -0500
Hi Dirk,

This does not directly address your question, but is some related
information.  We are working on coming up with a new model for motor
device and driver support that is much cleaner than the old model.  It
will be easily extensible to take advantage of controller specific
features, and will have a standard way to do:

- Deferred (synchronized) moves where all axes in the move start at
exactly the same time (within the controller's capabilities)

- Profile moves, where all the axes in the move travel along a
predefined path in N space, and put out detector synchronization pulses
along the path (again, within the controller's capabilities).

I am appending a message I sent to the Diamond developer's about this
yesterday.

Cheers,
Mark



************************************************************************
************
************************************************************************
************
Hi Matt and Nick,

I wanted to let you know I've been doing some work on the motor
software.

I now have the new Model 3 C++ base classes working, and I have now
implemented 3 controllers: simulation, Parker ACR series and the Newport
XPS.

I've got doxygen documentation for the base classes and the ACR driver
done:

http://cars9.uchicago.edu/software/epics/motorDoxygenHTML/classasyn_moto
r_controller.html

The source code is in Subversion

https://subversion.xor.aps.anl.gov/synApps/motor/trunk/

MotorSrc/asynMotorDriver.*
ACRSrc/ACRMotorDriver.*
MotorSimSrc/motorSimDriver.*
NewportSrc/XPSMotorDriver.*
iocBoot/iocWithAsyn/st.cmd.acr, st.cmd.sim, st.cmd.xps3,
motors.substutions.acr, motors.substitutions.sim,
motors.substitutions.xps3

I'd be very interested to get your comments.

Compared to the previous asyn support (what I call model 2) this new
model 3 makes it much easier to add new controller-specific parameters.
The XPS and ACR do that now, with both supporting jerk time, and the ACR
supporting 32 bits of binary I/O.  It also uses the infrastructure of
asynPortDriver, which was developed for areaDetector, and so we no
longer need the param_lib that was in motor.

My plan now is to test the XPS some more, and then move to incorporating
the coordinated motion, moving it from the SNL program into the driver.

Are you guys interested in moving the PMAC support to this new model,
and seeing if we can come up with an API for coordinated motion that
works for both the XPS and PMAC?  Tim Mooney has already got coordinated
motion working with SNL code on the OMS MAXv, so it would be great to
migrate the MAXv to the new architecture as well.

I have a question for you.  Can you please explain the purpose and use
of the "deferred moves" logic in the XPS driver again?  I know you've
told me before, but I forget.  Can you send some screen shots of the
user interface?  Is this something to address shortcomings in the XPS,
or is it a concept that belongs in the asynMotorController base class?

Cheers,
Mark

************************************************************************
************
************************************************************************
************

-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Dirk Zimoch
Sent: Friday, April 01, 2011 7:37 AM
To: EPICS
Subject: MAXv question

Hi all,

Is anyone using the @DPM_ON@ feature of the MAXv motor driver? I would 
like to modify it.

At the moment this feature allows to use the general purpose bits 0...7 
as inputs to monitor the motor power. At the SLS our motor amplifiers 
support this feature. Thus it might be that it had originally been added

by us (David Maden) for the OMS VME58 but I am not sure.

Now for the MAXv I would rather use bits 8...15 because bits 6 and 7 are

not available on the backplane, only on the front connector, and we use 
a backplane transition module to connect our motors.

And I would like to integrate that change into the main software branch.

  So before breaking anything: Does anyone see a problem with that?

Dirk





References:
MAXv question Dirk Zimoch

Navigate by Date:
Prev: MAXv question Dirk Zimoch
Next: Re: MAXv question Ron Sluiter
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: MAXv question Dirk Zimoch
Next: Re: MAXv question Ron Sluiter
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·