Re: Reply to Ben Ocko re: pseudomotors

[Tim Mooney <mooney@aps.anl.gov>]

re...

> > [Ben Ocko:]
> >     I would like to solicit your advice about EPICS.  My limited
> > understanding is that you can write EPICS code to create a psuedo motor
> > that will drive more than one actual motor using a  user  defined
> > function.  Whereas there is a standard EPICS subroutine call to move a
> > normal motor, there is no such call for these psuedo motors. If this
> > were the case, one could use the standard SPEC scans without further
> > modifications. This is important, for instance, if you want to move a 3
> > legged table up and down and you only care about the height and not the
> > level.  Other psuedo motors might
> > adjust the level keeping the height the same. the level.
> 
> [Mark Rivers:]
> You are pretty much correct.  It is not a subroutine call, but rather an EPICS
> motor record, which you can think of as an 'object' in the programming sense. 
> The motor record has standard fields (or properties) like DVAL (the drive
> position in dial units), DRBV (the drive readback in dial units), DMOV (a flag
> which says if the motor is done moving), etc.  EPICS moves individual motors
> with this record.  The problem is that compound motors (the height of a lift
> table) have not been done in a standard way.  There is a 'table record' which
> Tim Mooney wrote which lets you drive a lift table, but it does not have the
> same field names as a standard motor.  Because it is a single record it cannot
> have the same field names, since there would need to be multiple DVAL fields,
> for example, and there can only be one field of a given name per record.

It's probably fair to say that there *is* a standard EPICS call to move
a pseudomotor (or anything else) implemented in EPICS.  As Mark notes,
the essential difference between a real EPICS motor and a pseudomotor
implemented in EPICS is in the naming of the fields by which it is
controlled.  For example:

function         real motor   pseudo (table height)   pseudo (slit width)
-------------------------------------------------------------------------
write position   P:m<n>.VAL   P:table<n>.Y            P:Slit<n>Hxn.VAL
read position    P:m<n>.RBV   P:table<n>.EY           P:Slit<n>Ht2.B
get status       P:m<n>.RBV   P:Table<n>:done.VAL     P:alldone.VAL
stop             P:m<n>.RBV   P:Table<n>:stop.VAL     P:allstop.VAL
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
calibrate mode   P:m<n>.SET   P:table<n>.SET          P:Slit<1>Hset.VAL
set speed        P:m<n>.VELO  <not supported>         <not supported>
set acceleration P:m<n>.ACCL  <not supported>         <not supported>

This is not a particularly attractive solution because it requires
clients to know too much about how a pseudo motor was implemented, and
(worse) to change when the implementation changes.  But I know that it
works because this is the way I supported EPICS pseudomotors when I
ported Super to EPICS back in 1994.

> [Mark Rivers:]
> I am completely convinced that what you propose is the right way to do it.  We
> need to make an EPICS pseudomotor record which has all of the same fields as
> the EPICS motor record.  The pseudomotor record would actually do very little.
> It would check soft limits and do a few other things.
> ...
> I am hoping that Ron Sluiter and Tim Mooney will do this, and I have heard
> rumors that they are.  It should not be too difficult, and I and others have
> been asking for it for a long time.

I agree with most of this, and we've been trying to figure out how best
to do it, but the problem should not be simplified.  If clients are
just going to lay there and pretend there's no other way to treat a
collection of EPICS records as a scannable thing, then the pseudomotor
record will be the only mechanism by which users can scan non-motorized
devices, so it should connect with anything a user might ever want to
scan--e.g., temperature controllers, piezos, DAC channels, regions of
interest in MCA spectra, and other devices we don't know about yet.

I think the pseudomotor record has to support as many of the motor
record's fields as is practical because it's going to be used as the
front end for actual motor support in some cases.  It will be used to
control non-motor devices that require backlash correction, for
example, or that allow a speed specification--and how else should users
specify those things than by setting pseudomotor fields?  It should be
possible for any client of the motor record to use the pseudomotor
record instead, and this includes other EPICS records such as the table
record.  Finally, because users can implement their own pseudomotors at
run time, the pseudomotor record should expect to be retargeted at run
time, and any client that talks to it should expect the fields to be
volatile.  Otherwise users will want hundreds of pseudomotors prelinked
to every likely scan target.

The current plan is to add link fields to the motor record, and to
write soft device support for the motor record that will use those
links to communicate with a pseudo motor implemented with other EPICS
records.

> [Gerry Swislow:]
>...
> Another issue of standardization concerns naming of the
> pseudomotor channels.  Spec uses what seems to be the
> convention for naming EPICS motors, in that process
> variable names are formed from a 'prefix' plus the letter
> 'm' plus an integer starting from 1.  The 'prefix' can be
> any string.  In the spec configuration file, each motor is
> given a unit and a channel number. The unit number is
> associated with a particular prefix. The channel number
> can be any integer.

I'm guessing that a naming convention for all pseudomotors would not be
adhered to uniformly.  Also I would really dislike forcing users to
name in advance every thing they might want to scan.  Is it possible
for a scan command simply to name a pseudomotor record, as in

scan 'xxx:slit1H_width' <start> <end> <increment>



Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls &amp; Data Acquisition Group
Advanced Photon Source, Argonne National Lab