Reply to Ben Ocko re: pseudomotors

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

From:	CARS3::RIVERS       'Mark Rivers' 23-JAN-1999 10:33:50.53
To:	SMTP%'benocko@pouch.com'
CC:	RIVERS
Subj:	RE: EPICS/psuedomotors


Hi Ben,

>     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.

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.

When we use the standard EPICS scanning tools this is not really a problem,
because I can tell it to scan any EPICS field, wait for any other EPICS field
before proceeding, etc.  However, SPEC only knows how to drive the EPICS motor
record, not any arbitrary EPICS field (though you can do that with SPEC
macros).

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.  The actual work would
be done using an EPICS State Notation Language program in the VME crate which
detects commands to move pseudomotors and moves the real motors, reads back
the positions of the real motors and computes the positions of the
pseudomotors.  I have already done something similar in EPICS for 2
applications:
- A general purpose 2-D coordinate transformation.  Given one X-Y
  coordinate system, you can move pseudomotors in another coordinate system
  which is translated and rotated with respect to the first.
- A pseudo 2-theta arm, which is made of an X-Y-theta stages.  One can drive
  this device with the pseudomotors Radius and Theta.

The problem with my system is that since there is no pseudomotor record I had
to do this with a collection of standard EPICS records (like analog out and
binary out).  Thus, the field names are not the same as the motor record and
SPEC can't drive them.

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.  If it does not happen soon I will do it
myself when I can.

Cheers,
Mark