Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Fri, 11 Dec 2009 07:43:37 -0600

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