RE: Draft requirements document for enhanced EPICS motor support

[<nick.rees@diamond.ac.uk>]

Tim's response has just driven me to respond as well - in that I agree with him, the consistency of interface enforced by the motor record has served us very well. The major failing with the level 1 driver was that it forced exclusive use of the axis by a single motor record - nothing else could move the axis, but that was the failing that was fixed in the model 2 developments. This allows different systems to control an axis without the motor record getting confused. The amazing thing was that we managed to do this with minimal changes to the motor record itself.

Any interface variation allowed by the use of individual records screws up any higher level software that depends on this interface. So I don't see re-engineering the motor record as a priority - it would be too easy to break things. This isn't normally a problem in single developer environment, but at Diamond, where we have lots of developers with varying levels of experience, the consistent interface is a rock we build on. 

Having said all this, motor record ideas I do have that aren't covered are:
 - possibly having a base class/derived class relationship between a simple motor record and the full motor record capability. I have always had an ambition for generating a simplified motor record which would satisfy 99% of needs and eliminate 99% of confusion, but never got around to it.
 - looking at a V4 RPC interface. This could possibly map onto the V3 motor record as well as something completely new. It would eliminate the concern about consistency of interface since we would separate the interface from the implementation. You could define the move you want via a union that is sent to the controller - the union could represent one axis, or any arbitrary complex move.

These are both actually trying to preserve the interface somewhat, but extend the flexibility.

However, the real driver for development must be to satisfy the needs for complex arbitrary scans used, for example, for mapping operations. These could be defined functionally and with PVT and/or spline fitting mechanisms. This has to be coupled with triggering and position capture capability. I note that all the requirements in the document relate to these sort of developments and I think this reflects the reality we all see (there aren't any major requirements to redevelop the motor record - apart from software purity concerns such as supportability, I wouldn't do it that way if I did it now, etc etc).

Finally, as somewhat trivial comments, I would mention (at the end of the history) that if multi-axis moves can be parameterised to be a seen as changing a single parameter (e.g. a distance along a curved trajectory where the velocity corresponds to the feed rate) then a motor record is still a good interface, with resolving the parameter to physical axis transform being done in the motor controller. We have done this extensively. Similarly, even if it is a multi-parameter system (like a hexapod) the virtual axes can be easily mapped to single motor records. We have also used this extensively.

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713


-----Original Message-----
From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov] On Behalf Of Mooney, Tim M.
Sent: 26 May 2015 17:29
To: Rivers, Mark L.; EPICS-motor-wg@github.com; EPICS Tech-Talk
Subject: RE: Draft requirements document for enhanced EPICS motor support

Hi Mark,

I started to edit the requirements document, but the premise seems to be that we would like to get rid of the motor record if only we could.  I don't feel this way.  I think it's a very valuable implementation of the behavior needed for nearly all the motors on APS beamlines.  An important but small number of motors need a better model to do complicated motions, and I'd like to focus my effort on those needs, without also pursuing the goal of reimplementing stuff that works.

However, I also agree that at least some of the state-machine aspects of the algorithm the motor record mplements would be much easier to code and maintain in a driver, because a driver can block and a record can't.  On the other hand, a record has a special() routine and a driver doesn't.

In any case, I would like to retain at least one behavior of the motor record: the ability to set a speed, start a motion, and then immediately return the speed to its previous value without affecting the motor motion in progress.  The table and monochromator software expect this behavior. It's certainly possible for software to wait until the motor has finished moving to reset the speed, but it's more complicated and error prone to do this.

Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab


________________________________________
From: tech-talk-bounces@aps.anl.gov [tech-talk-bounces@aps.anl.gov] on behalf of Mark Rivers [rivers@cars.uchicago.edu]
Sent: Monday, May 25, 2015 3:03 PM
To: EPICS-motor-wg@github.com; EPICS Tech-Talk
Subject: Draft requirements document for enhanced EPICS motor support

Folks,

I have created a straw-man requirements document for enhanced EPICS motor control in the new EPICS-motor-wg project on github.

https://github.com/EPICS-motor-wg/discussions/blob/master/documents/Requirements.md

If interested please take a look.  You can make contributions via the pull request mechanism on github.

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