Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Thu, 17 Dec 2009 00:42:04 -0600

Folks,

I have now made a first pass at a new version of asyn motor support.  Here's what I have done:

-          Changed the existing asyn motor support (devMotorAsyn and drvMotorAsyn) as follows:

o       devMotorAsyn previously used hardcoded enum values to set pasynUser->reason.  This is not a good design, it should use the drvUser interface to get the pasynUser->reason values.  I have made this change.

o       drvMotorAsyn.h previous published the enum values, rather than drvInfo strings.  drvAsynMotor.h has now been replaced with asynMotorDriver.h, which only publishes the drvInfo strings.  It defines a symbol for each string.  The other values previously defined in drvMotorAsyn.h have been moved into drvMotorAsyn.c, because they are only needed there.

o       Previously a new asyn interface, asynMotorStatus, was defined to pass combined position and status information.  There is no longer any need to define a new asyn interface for this purpose, the standard asynGenericPointer interface can be used.  I have deleted the asynMotorStatus interface and replaced it with the asynGenericPointer interface.

These changes only affect devMotorAsyn.c and drvMotorAsyn.c, they do not have any effect on motor drivers written with the previous asyn motor interface.  I have tested the existing simulation and XPS drivers and they seem to work fine.

I have written a new version of asyn motor support that is written in C++.  It uses the asynPortDriver class from the asyn module.  It consists of the following:

-          A base class, asynMotorDriver, that inherits from asynPortDriver.  It is the class from which motor drivers are derived.  The files asynMotorDriver.h and asynMotorDriver.cpp have been added to motorApp/MotorSrc/.  This file essentially replaces drvAsynMotor.c.  The existing device support, devAsynMotor.c is used with the changes described above.

-          A new C++ version of the simulation motor driver that inherits from asynMotorDriver.

The simulation driver is basically working, though I am sure there are bugs.

I like this new solution, it is now trivial to add additional features to a driver without having to use an asynInterposeInterface layer.  It is also trivial to implement other asyn interfaces, like asynOctet, for string communication with the driver, etc.  The total amount of code in the motor module is decreased appreciably.  Writing a new driver is significantly simpler.

My plans:

-          Test he new simulation driver, add additional parameters and interfaces to demonstrate how this is done.

-          Convert the Newport XPS driver to this new C++ model.

-          Convert the MAXv to this new C++ model.

-          Implement coordinated motion in the XPS and MAXv through this new interface.

I'd appreciate any comments.  The code is available for review and testing at:

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

Cheers,

Mark

________________________________

From: Mark Rivers
Sent: Fri 12/11/2009 9:00 AM
To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: Rethinking asyn motor drivers

Nick, Matt, and others,

I would like to continue the discussion we had at the Codethon about rethinking the asyn motor driver structure before it is too late, e.g. too many drivers written with the current approach.

The current approach isolates the motor driver from asyn, using a device-independent drvAsynMotor layer which implements asyn interfaces, and calls an asyn-independent set of motor-specific functions.  This approach has some advantages, but also has some significant disadvantages.

Among the disadvantages:

- It is difficult to support additional parameters beyond those supported by the motor record.  It is not impossible, but it requires writing an asynInterposeInterface driver to implement the asynDrvUser interface, and then passing those additional parameters to the motor driver through the drvAsynMotor layer, but without it understanding what the parameters mean.  But even that approach only works for the asyn interfaces that drvAsynMotor implements, e.g. asynInt32, asynUInt32Digital, asynFloat64.  What if I want my driver to support the asynInt32Array interface to return an array of captured motor positions, or to implement the asynOctet interface to send/receive strings from the controller?  There is no way to do that with the existing model.

- The callback function in the paramLib does not work with standard asyn device support, because it passes an array of changed parameter indices, rather than the standard asyn callback interface.  Thus, if my driver wants to implement a new parameter, say a float64 readback of the drive current, it has no way to do callbacks to standard asyn device support to update that value in an ao record with SCAN=I/O Intr.

- Each time we add a new capability to the drivers (e.g. trajectory scanning) we need to create a new function in motor_interface.h.  If however the motor drivers directly implemented the standard asyn interfaces, we could use the existing interfaces (e.g. int32Array) without having to modify any C interfaces.  We would just add a new drvInfo string for that new functionality.  Existing drivers that don't implement that functionality would just return an error when the drvInfo string was parsed at iocInit.

- motor_interface.h uses hard-coded enum values (e.g. motorAxisPosition=0) and drvInfo strings (e.g. "POSITION").  As I have learned recently when writing a driver that implements multiple interfaces (areaDetector, dxp, and mca), this does not work.  Only the drvInfo strings should be published and device support must use only those strings, not the enum values, when communicating with the driver.  The problem arises because if the motor interface defines a command enum to be 0 and so does some other interface (e.g. mca) then there is a conflict.

For all of these reasons and more I would like to propose that the approach taken with areaDetector be used with motor drivers as well.  The motor drivers would directly implement the asyn interfaces.  But they would do this through the asynPortDriver C++ class that isolates them from almost all of the bookkeeping details of asyn.  There would also be a new asynMotor base class that would implement a lot of the common functionality, leaving only the controller-specific code to be implemented in a particular driver.  I have recently re-written the asynPortDriver class, the MCA device/driver support and the areaDetector drivers to eliminate the use of enum values to control asynUser->reason.  That way a driver can implement multiple interfaces with no problem, and the new DXP driver does this.

With this approach it is easy to:

 - Add controller-specific parameters in addition to a set of base parameters that the motor record and all drivers will implement.  

- Implement complex things like trajectory scanning down into the driver layer, where it belongs.  

- Implement additional standard interfaces, like asynOctet.  With this model the MAXv driver could implement asynOctet for basic string I/O to the controller, eliminating the need for an additional driver like I was proposing in an earlier message today.

Thoughts?

Mark

________________________________

From: Mark Rivers
Sent: Fri 12/11/2009 7:43 AM
To: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: RE: OMS MAXv driver

Hi Austen,

That's good news, thanks.

Here are a couple of clarifications of what I'm proposing:

1) I think you are working on an asyn motor driver, along the lines of the ones for the PMAC and Delta Tau.  That is important and badly needed.  But what I am proposing is actually asyn port driver one layer below that, which simply implements the asynOctet interface.  That way I could use an asynRecord to simply send and receive strings from the card.  This is the approach Diamond has taken with the Delta Tau, and I like it.  Then your motor driver would talk to that underlying driver for the string based I/O.  That underlying driver could also implement the asynInt32 for non-string based I/O if that makes sense too.  This approach should let a single motor driver work with the MAXv (VME), the MAXNet (Ethernet), and the PCI card.  Only the underlying asynOctet driver would be different.

2) I don't think deferred moves and trajectory scanning are the same thing.  Deferred moves lets one set a single target position for each of several motors and then start them moving all at once.  Diamond added that feature to the XPS driver, for example.  Trajectory scanning means downloading an array of target positions, say 1000 points, for each of several motors, and then have that entire array of positions be executed inside the controller as a coordinated non-linear motion.  This is supported now for the MM4005 and XPS controllers using SNL programs.  This is what I want to implement for the MAXv, using it "contouring" command capability, e.g. the "CD" command.

Here's the reference to the trajectory scanning documentation in case you are not familiar with it:

http://cars9.uchicago.edu/software/epics/trajectoryScan.html

One thing that is on the to-do list is to move trajectory scanning down into the asyn motor drivers, rather than running it as an SNL program.  That is a worthy goal, and we should talk about it, but for now I would be happy to have the MAXv use the SNL approach just to get it going.

Mark

________________________________

From: [email protected] [mailto:[email protected]]
Sent: Fri 12/11/2009 5:18 AM
To: Mark Rivers; [email protected]; [email protected]; [email protected]; [email protected]
Cc: [email protected]
Subject: RE: OMS MAXv driver

All,

A copy of the reply I sent directly to Mark:

Hi Mark,

I am a fair way down the route of implementing an asyn based driver for
OMS-58 card. I need to finish off some work on primitives and will then
need to port it to MAXv. It'll also need some decent testing, as I am
developing it on an 8S and would like to make sure it behaves on a
stepper controller. I'd also like to circulate my code for a bit of a
review by those who have far more experience and knowledge of the motor
support module than myself.

Once the above is in place, I was contemplating moving on to coordinated
motion too. We call it deferred moves at Diamond, for some reason.

I am currently held up on some other work I need to get done. So do you
have any specific timescales and or needs?

I am hoping to have the OMS version finished before the Christmas break.
I need the MAXv version fairly shortly afterward for a new project, and
I also need deferred moves operational early in the new year.

Regards,

Austen Rose

Austen Rose

-----Original Message-----
From: Mark Rivers [mailto:[email protected]]
Sent: 10 December 2009 18:35
To: [email protected]; [email protected]; Pearson, Matthew
(DLSLtd,RAL,DIA); Rees, Nick (DLSLtd,RAL,DIA); Rose, Austen
(DLSLtd,RAL,DIA)
Cc: [email protected]
Subject: OMS MAXv driver

Folks,

I am thinking about implementing coordinated motion on the OMS/Pro-Dex
MAXv controller.  To do so I think it would first make sense to
implement an asynOctet driver for the MAXv, to abstract the string
communication.  This is what Diamond did for the DeltaTau PMAC series,
so that the same higher level software can communicate with PCI, VME and
Ethernet based PMACs.

My question is whether anyone else has started (or completed!) doing
this for the MAXv and/or OMS58?

Thanks,
Mark

--
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System