Re: Reply to Ben Ocko re: pseudomotors

['jennings' <jennings@anl.gov>]

This is something I had been meaning to do for some time - (but haven't got
a round tuit!!!)

I was intending to implement this as a portable channel access server
program, using some scripting language such as tcl/tk to implement the
geometry transformations.  I'd then run it as a task on a linux box
somewhere.

If we can come up with a reasonable minimum set of fields I'll follow it!!
My instincts lean towards a very minimal set - in my case I don't want the
configuration to be controlled by record fields - I'll do it myself in the
scripting language.

----------
>From: Gerry Swislow <certif!gerry@photon.mit.edu>
>To: Mark Rivers <cars3.uchicago.edu!RIVERS@photon.mit.edu>
>Subject: Re: Reply to Ben Ocko re: pseudomotors
>Date: Sun, Jan 24, 1999, 10:19 AM
>

> 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