Re: Reply to Ben Ocko re: pseudomotors

[Gerry Swislow <certif!gerry@photon.mit.edu>]

Arun Bommannavar wrote:

> As long as we have your attention, Gerry, how does Spec handle CNTRL-C
> with respect to pseudomotors?

Let's be clear.  Spec has its own internal pseudomotors, sometimes  
implemented in C code (such as for a gamma-rotation plus gamma-translation  
equals detector rotation on a six-circle diffractometer) and sometimes in  
macros (as is often done at ESRF for all sorts of things).  However, in  
both cases these pseudomotors are tied to real motors also configured in  
spec.  When a user types ^C to stop the current motion, the real motors  
associated with the pseudomotors are halted.

However, the current discussion about EPICS pseudomotors describes a  
different situation.  From spec's point of view, these EPICS pseudomotors  
will be treated like real motors.  Spec will have no knowledge of the  
physical motors associated with the EPICS pseudomotors.  When a user types  
a ^C to halt the motors, spec will send through channel access the agreed  
upon command that stops EPICS pseudomotors, just as it sends a .STOP to  
stop a standard EPICS motor.  The EPICS side then does its magic to stop  
the real motors.

The motivation behind this news-group thread is that I can't build into  
spec a standard set of commands to start, stop, read position and get  
current status for these EPICS pseudomotors, because there is no agreed  
upon standard for the process variable names or the channel names, as  
there is for the standard EPICS motors.

If the standard names for the commands were:

.RRBV to read back the current position
.RVAL to set the target position and initiate a move
.STOP to stop a move
.DMOV to indicate starting/stopping status
.HLS to indicate hitting the high limit
.LLS to indicate hitting the low limit

and the motor name was formed by a prefix + 'm' + an integer, then spec's  
existing motor support would work with the EPICS pseudomotors with no  
change to the spec code.

The above set of names doesn't seem like the most descriptive set for the  
desired functionality, though.  I'm perfectly happy to implement a new  
set of names for the new (and 'real' to spec) motor type of EPICS  
pseudomotor.  The problem is for all the different people who are working  
with EPICS at APS to agree on something.  I ought to be able to make any  
necessary modifications in spec in very short order, once I know what the  
standard will be.

Gerry