[Date Prev][Date Next][Date Index]
Re: Reply to Ben Ocko re: pseudomotors
Mark wrote:
> Gerry wrote:
> > I don't understand what these 'geometry fields' are for. Do I need to?
>
> What I mean is a place to store geometric constants or
> variables for the pseudomotor device. For example on a
> lift table the distances between the pivot points are
> needed in order to have a 'tilt' pseudomotor work in
> absolute units of degrees or mrad. For a lift table there
> might be half a dozen such geometric constants. The lift
> table will probably have 3 to 6 pseudomotors (X, Y, Z, AX,
> AY, AZ). If each pseudomotor has 4 fields where geometry
> information can be stored that is more than enough. It is
> up to the person who implements the code for the lift table
> to define, for example, that the distance from the Y1 jack
> to the line between the Y2 and Y3 jacks is stored in the G1
> field of the Y pseudomotor, etc.
>
> Mark
It seems simpler if the definition for this layer for generic
pseudomotors not have to include such device-specific parameters. It's my
impression that EPICS drivers are layered. For example, isn't the OMS
driver (motor record) layered underneath the EPICS code for the height,
tilt, etc. pseudomotors that describe a table pseudo-device? Can't an
application talk directly to the OMS motor records to move a real motor
associated with a table leg, with the pseudomotor positions associated
with tilt, height, etc. all suitably updated?
Couldn't there be a very basic standard pseudomotor level to deal with
the minimal start/stop/read/get_status needed for scans that could be
layered on top of all the various pseudo-devices? The point is to be able
to fit this pseudomotor interface onto all the existing non-motor, but
scannable-type devices/pseudo-devices with minimal effort. If layered as
described here, wouldn't all existing applications that talk directly to
the existing pseudo-devices continue to work without modification?
(This all coming from someone with no experience on that side of EPICS.)
Gerry