Re: Reply to Ben Ocko re: pseudomotors

[Mark Rivers <RIVERS@cars3.uchicago.edu>]

Gerry Swislow wrote:

> I don't think an EPICS pseudomotor record needs to have all the
> same fields as the EPICS motor record.  The EPICS motor
> record is pretty complex and requiring pseudomotor
> records to deal with that complexity will probably slow
> down any implementation.  I'd say minimum capabilities
> need only include:
> 
> start           (move to a position)
> read            (read current position)
> get status      (busy/ready/fault/...)
> stop            (abort move)
> 
> Other _optional_ capabilities could include:
> 
> set position            (set/calibrate current position to a value)
> set speed
> set acceleration

I think the pseudomotor record should have all the motor record fields in 
the .dbd file.  That is easy.  The code which implements the pseudomotors
record will only pay attention to a very limited subset of the fields, as you
suggest.

The pseudomotor record also needs a few additional fields beyond those in the
motor record.  These fields would be used to store geometry information,
probably 4 geometry fields per record would be enough.  It would be up to the
implementer of a particular pseudomotor geometry (slit, 3 axis lift table,
etc.) to define the meaning of the geometry fields in each record.

Can you tell us what fields SPEC currently uses in the EPICS motor record
(VAL, DVAL, DMOV, etc.)?  If we do it right it seems to me that SPEC should
not even know that it is talking to a pseudomotor rather than a real EPICS
motor.

As for a standard naming convention, how about prefix:pm1, prefix:pm2, etc.

Mark Rivers