Motor record news

["Denison, PN \(Peter\)" <peter.denison@diamond.ac.uk>]

After several questions at the recent ICALEPCS meeting, I realise that I haven't communicated the current status of the recent work on the motor record drivers very effectively. Hopefully I can here.

The work to implement a new device and driver layer for the "motor" record and to provide a new API against which to write motor controller drivers is now substantially complete. It has been in use at GSE-CARS at APS and at Diamond for over six months, and has been well tested during this time. It is the developers' opinion that new motor drivers should be written against this new model (well it would be!). We believe that it will be a lot simpler than trying to use the existing structure from scratch.

Preliminary versions are available in the motor releases between 5-9 and 6-2-2, but there are updates that will be in the forthcoming 6-3 release. The API has not changed, but there have been a few bug-fixes.

Examples of drivers using the new model are the Newport XPS and MM4000 controllers within the motor record release (motorApp/NewportSrc/drv*Asyn.[ch]), a simulated motor (motorApp/MotorSimSrc/*), and the tpmac driver at http://www.gmca.aps.anl.gov/TPMAC2/tpmac3-4.zip. More documentation on the tpmac driver will follow. If you wish to use it in the meantime, please drop me a line.

Work is underway on a driver to support DeltaTau PMAC coordinate systems, and on moving the OMS series of controllers (58, Vmax) to the new model.

=========================================================================
More technical detail:
The new motor device and driver layer decouple the motor record support from the controller driver, using the Asyn framework. In several cases this results in two layers with Asyn ports - 1 implementing the motor Asyn interface, allowing both motor records and other primitive records (ai, ao, etc.) to connect to the common set of features that the motor record uses, such as demand position, velocity, limit positions. This interface can be extended for a particular controller using the Asyn interpose mechanism. The XPS driver has an example of this.

Where the underlying communication to the controller uses a serial or network port, a second asyn port is used for this communication. This allows bespoke records to be connected to the controller (alongside a standard motor) for a particular feature (e.g. applying a brake on an axis). All locking and synchronisation is handled by the Asyn framework. One other side effect, seen on the PMAC family of controllers, is the ease with which the underlying transport can be switched from VME backplane to serial port to ethernet, just by specifying a different Asyn port.

If there are any questions, in particular if you'd like to implement a driver against the new model, please get in touch.

-- 
Peter Denison, Senior Software Engineer
Diamond Light Source Ltd., Diamond House, Chilton Didcot, Oxon, OX11 0DE
+44 1235 778511






<DIV><FONT size="1" color="gray">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
</FONT></DIV>