Jump to content
OMRON Forums

Recommended Posts

Posted

I am using a PPMAC to control a zoom lens. I have characterized the lens in the sense that I have a table of motor counts required to get to the various magnification markings on the lens.

 

If I manually jog the lens to an arbitrary motor position, I want the PPMAC to tell me what magnification I am on.

 

Conversely, I want to be able to enter an arbitrary magnification and then be able to command the motor to a position that represents that magnification.

 

Using regression, I have modeled the characteristic of the lens (magnification versus motor counts) and I can implement functions in the PPMAC to get from magnification to motor counts or vice-versa.

 

However, I'm wondering if I can do this in the PPMAC using compensation tables and PPMAC's built in cubic interpolation capabilities?

 

My actual table of magnification versus motor counts is not equally spaced because the markings on the lens are not equally spaced. I suppose I could generate a table that is equally spaced.

 

Again, I need to go both ways, jog to arbitrary position, have the system tell me what the corresponding magnification is, later, enter an arbitrary magnification, have this translated to motor units.

 

Am I nuts to try this using compensation tables? Suggestions for how to get started?

 

Thanks;

  • Replies 4
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted

If you have functions for this already it would be easy to use the following sequence in your program:

Motor[1].ProgJogPos = {your calculation}

Jog1=*

You could incorporate this into a subroutine with variables to pass the data in and out.

Posted

You may want to consider using the kinematics subroutines to convert between your magnification values and the matching motor positions.

 

The forward kinematic subroutine would convert from motor position to magnification ("axis") value. This would be used for reporting purposes. (It is also needed to compute present "axis" value when starting a motion program.

 

The inverse kinematic subroutine would convert from magnification value to motor position. When you command an axis value, this is used to compute the underlying motor position.

 

The mathematical functions in these two subroutines must be exact inverses of each other, so for any position you can convert back and forth and end up with the same value.

Posted

My model functions are not exact inverses of each other and so they do not convert back and forth exactly. Going full circle, from desired magnification to motor counts and then back to indicated magnification introduces errors of up to about plus and minus 0.7% which may or may not be acceptable to my customer. The models are higher order polynomial functions and I can't invert them exactly. That's why I liked the idea of the PPMAC compensation tables and the fact that they perform an interpolation that passes through the known points. The thought of "pinning" the interpolation exactly at the 12 or so known data points is attractive. So here are several key questions.

1. If I were to use compensation tables to get from mag to motor units, is there a way to get back? IE: are compensation tables bi-directional or invertible so that I can get from an arbitrary actual motor count back to a corresponding magnification?

 

2. I think compensation tables require equidistant spacing of the data points do they not? If so, then I'm not really pinning to known points, I'd be pinning the PPMAC interpolation to equidistant points that I manually interpolated from my non equidistant data points.

 

3. Given that I probably cannot come up with mathematical functions that are exact inverses of each other, does this rule out the use of kinematic subroutines suggested above?

 

Thanks;

M Shaver

Posted

To answer your questions:

 

1. The tables have no automatic inversion function. The math to do the inversion is fairly complex for first-order interpolation; I have not even attempted it for third-order interpolation.

 

2. Yes, the tables require equally spaced points.

 

3. The problem that comes from FK and IK conversions that are not exact inverses of each other is this: At the beginning of a motion program, the FK routine is automatically called so that that starting axis position (your magnification value) is computed from the present motor position. Immediately after this, the first little programmed increment (a segment of a few milliseconds) of the commanded axis trajectory away from this starting position is converted to motor position through the IK routine.

 

If the two functions are not exact inverses of each other, there will be a jump in executing the first cubic position segment from the starting point to the first segment endpoint. If it's really bad, say due to an outright programming error in the routines, this could cause a fault. I doubt that 0.7% would cause any kind of fault, but you (and/or your customer) would have to assess whether it is tolerable or not. This could be tempered somewhat with a trajectory pre-filter acting as a low-pass.

 

I should mention that many people do an iterative solution for one of their routines, especially for the FK, so they can get it to converge very closely to the true inverse of the other function.

Guest
This topic is now closed to further replies.

×
×
  • Create New...