Re: Reply to Ben Ocko re: pseudomotors

['Arun Bommannavar' <arun@anl.gov>]

-----Original Message-----
From: Gerry Swislow <certif!gerry@photon.mit.edu>
To: Mark Rivers <cars3.uchicago.edu!RIVERS@photon.mit.edu>
Cc: APS.ANL.GOV!BEAMLINE_CONTROLS@photon.mit.edu
<APS.ANL.GOV!BEAMLINE_CONTROLS@photon.mit.edu>
Date: Sunday, January 24, 1999 11:11 AM
Subject: 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?
>

Yes, any client can talk to the real motors directly. The client application
will then have the responsibility of maintining the relation between the
real motors for each pseudomotor. If on other hand the code (in some form of
record or some such thing) is running in the IOC, then any client can run
the pseudomotor and not have the burden of maintaining the code. I am also
of the opinion that pseudomotors should not include device-specific
parameters.

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

Indeed that would be great.

>(This all coming from someone with no experience on that side of EPICS.)
>
>Gerry
>

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

Regards


**********************************
Arun S. Bommannavar    Voice (630) 252 - 0333
Bldg.No. 433-A008          Fax    (630) 252 - 0339
9700 South Cass Avenue
Argonne National Laboratory  E Mail  arun@anl.gov
Argonne, IL 60439