[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