[Date Prev][Date Next][Date Index]

Re: Reply to Ben Ocko re: pseudomotors




Mark Rivers wrote:

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

I defer to your vastly greater EPICS expertise on that.  The point is
to keep the standardized pseudomotor layer simple, so that existing
pseudomotor EPICS code can easily be adapted or layered under this new  
pseudomotor standard.

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

I don't understand what these 'geometry fields' are for.  Do I need to?

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

Here's the current list:

		     	       might_modify   is_monitored
ACCL    acceleration                    x       x
BDST    backlash distance               x       x
DHLM    dial high limit                 x       x
DIR     sign of user * dial             x       x
DLLM    dial low limit                  x       x
DMOV    doing move                              x
ERES    encoder resolution              x       x
FOFF    offset control                  x
HLS     high limit active                       x
LLS     low limit active                        x
MRES    motor resolution                x       x
RRBV    read back value                         x
RVAL    target position                 x
SET     set/use for calibrating         x
SPMG    stop/pause/move/go              x
	(spec just sets to 'go' on startup for 'EPICS_M1' motors)
STOP    stop motor                      x
VBAS    base rate                       x       x
VELO    steady-state speed              x       x
OFF     user/dial offset                x       x


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

Sounds okay to me.

Gerry Swislow
                                  phone:  (617) 576-1610
Certified Scientific Software       fax:  (617) 497-4242
PO Box 390640                     email:  gerry@certif.com
Cambridge, MA  02139-0007           Web:  http://www.certif.com