Experimental Physics and
Industrial Control System

<[email protected]> · Mon, 14 Dec 2009 12:53:26 -0000

Hi Mark,

I agree with all your points. Moving drvAsynMotor over to an
asynPortDriver derived class makes a lot of sense. The amount of code we
can get rid of will be significant, and the remaining code will be much
easier to understand and extend.

I hope to work on this again in spring, beamline projects permitting. I
plan to start with a motor controller simulator, then port the PMAC and
XPS drivers.

There are quite a few motor controller drivers written with the existing
interface. So we'll just have to port them on an as-needed basis. Long
term it makes sense though.

I think there might be some work to be done defining an interface for
trajectory scanning and position compare (position based gate and
trigger signals). The existing trajectoryScanning interface is very XPS
specific, and I don't know how well it will translate into Delta Tau
PMAC world, for which we need it. 

The position compare interface should be much easier to define. At
Diamond we already have a few different implementations of this for the
PMAC, and we are in the process of standardising the database interface.

Cheers,
Matt

> -----Original Message-----
> From: Mark Rivers [mailto:[email protected]] 
> Sent: 11 December 2009 15:01
> To: Rose, Austen (DLSLtd,RAL,DIA); [email protected]; 
> [email protected]; Pearson, Matthew 
> (DLSLtd,RAL,DIA); Rees, Nick (DLSLtd,RAL,DIA)
> 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
> 
> 
> 
> 
> 
> 
> 

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