Re: Comments on table record

[mooney@aps.anl.gov (Tim Mooney)]

Mark, re...

> I have been working with Tim's table record, trying to use it for a new 6-axis
> lift table we have.  I have run into problems with the geometry assumptions 
> behind the record, and would like to stimulate discussion about how the record
> could be enhanced or perhaps replaced by something more general.
> 
> Coordinate system:
>     Y - vertical
>     X - outboard
>     Z - downstream
> 
> The record assumes that there are 3 actuators with the following
> characteristics.
>     M0 has 2 actuators (X, Y)
>     M1 has 1 actuator (Y)
>     M2 has 3 actuators (X, Y, Z)
> 
> The record also assumes the following:
>   - When viewed from the top, the actuator positions in a clockwise direction
>     are M2, M1, M0.  This assumes a 'handedness' to the table, which
>     might not be true for other tables (M2, M0, M1).
> 
>   - The X slides are oriented parallel to the line between M0 and M1 and the Z
>     slides are oriented 90 degrees to this direction.  This is not true for 
>     the table I am using:  in my case the Z slides are oriented parallel to 
>     the line between M2 and M1 and the X slides are 90 degrees to this.
>     In general the slides might not be parallel to the lines between any pair
>     of positioners.

The assumptions mentioned above affect only the top level of code--the code that
calculates vectors from the point fixed under rotations to the three pivot points.
The rest of the code is more general and allows those pivot points to have any
locations and also allows X and Z motions to have any orthogonal directions.

I have a version of the table record (4.1) under test that appears to support
both the current geometry and the geometry you've described.  While working on
it, I discovered errors in some of the inverse-matrix elements that calculate
thetaZ from motor positions.

>   - The table has 6 degrees of freedom.  I have several tables with only 5
>     degrees of freedom (no Z motion).  In general one might have also tables 
>     with 3 degrees of freedom (vertical jacks only), 2 jacks (one translation
>     and rotation only), etc.

Version 4.0 and later of the table record support the use of fewer than six
motors.  (The table database that takes advantage of this also requires version
3.6 or later of the transform record, because earlier versions can't handle
links to nonexistent PV's.)

>   - There is a single fixed point for both the vertical and horizontal
>     directions.  We are using a pair of Kirkpatrick-Baez mirrors, so we need
>     the horizontal fixed point on one mirror and the vertical fixed point on
>     the other mirror.
>
> An additional limitation is the lack of soft limit checking on the compound
> motions.  We need to be able to allow large vertical translations, for example,
> so we cannot set hard or soft limits on the simple motors.  However, we need to
> restrict the pitch and roll of the table (AX and AZ) to small angles.

I haven't addressed these limitations.

> I think it would be good to get comments on other restrictions which people
> might feel the existing record has, and more importantly ideas on more general
> solutions.

I would really like to get away from the first-order approximations currently
underlying both forward and inverse transform matrices in the table record.  I
think it's important to preserve the ability to calculate virtual motors and
limits from motor positions and limits, and to allow users to change the fixed
point at run time.

Tim