Servo Hi-Lo

There has to be a way to do this mathematically...

You have a table with 12 stations, positioned evenly around the perimeter. You have a 2000 line quad encoder on your servo motor, for 8000 counts

8000 / 12 = yuck. Okay, 666.66667.

Different encoder is not an option at this time.

My thought is to use two indexed moves, since I have a little slop to work with. Overshoot a bit on one stroke, undershoot a bit on the other, so the error does not accumulate enough to matter. I'd planned on using 666 (lucky me) and 667, but this doesn't feel right.

Has anybody else tackled a situation similar, and how did you approach it?

TM

Don't forget to include any gear ratio in your calculations. Using your technique, you should do two moves of 667 counts followed by one move of 666 counts for zero cumulative error.

If you have a marker pulse (channel Z) available from the encoder, you could use it to reset your position at the end of each rotation and use absolute moves instead of incremental.

Depending on the brand of servo controller you're using, you might be able to define your system as a continuous rotary axis at 8000 counts per 360 degrees and let the controller handle the rollover for you.

Steve's right most newer servo's handle the non-repeating decimal quite well, I've used the Emerson/Control Techniques with a 10 station dial and 3:1 gearbox with no drift issues. Does your servo have the ability to do a Feed to Sensor Index?

TimothyMoulder said:

[BHas anybody else tackled a situation similar, and how did you approach it?[/B]

Click to expand...

Encoder resolution is not the culprit here... Mistake number one was letting the engineer use direct drive rather than an indexer...

That said, Steve's suggestion of using the Z-pulse makes the most sense to eliminate the accumulating error. Steve's last suggestion brings up another point. Can't you just specify "user units" and let the servo do the math for you? IOW 8000 counts = 360°. Then you can just tell it to move 30° for each index.

beerchug

-Eric

TimothyMoulder said:

There has to be a way to do this mathematically...

Click to expand...

Yes, a couple.

My thought is to use two indexed moves, since I have a little slop to work with. Overshoot a bit on one stroke, undershoot a bit on the other, so the error does not accumulate enough to matter. I'd planned on using 666 (lucky me) and 667, but this doesn't feel right.

Click to expand...

Why not? I would move 666,667,667 for a total of 2000.

Has anybody else tackled a situation similar, and how did you approach it?

Click to expand...

You bet. I would map the 8000 counts into 7200 position units. Then I can tell the system to rotate in just about any fraction of a turn I want and not lose counts. 7200 is divible by a lot of numbers

1,2,3,4,5,6,8,9,10,12,15,16,18,20,...

When the system rolls over 8000 counts one must subtract 8000 counts and 7200 position units.

Thanks!

I'm using a G&L DSM-009X indexing drive. I checked into the scaling options, using Peter's formula, and it should work perfectly. I'll let you all know how I make out

Incidentally, I'm interested in hearing how you can use the registration marker. I know the theory : Move to position, look for marker while moving, move to position based on marker. Flying shears and such.

But I'm curious how you would use it to take accumulated error out of an application like this? How would you implement that?

Thanks!

TM

If you had a "target" for each station you could use a prox sensor or photoeye and do a Feed to sensor index. This uses a high speed incemental index to do the majority of the move then decels down to a
slow "search" speed looking for the sensors input to come on.

And the result is...

After weighing all the methods described, the option that worked was... Yes!

First I tried mapping the drive to degrees, using the "units" parameter, but it didn't work, kept over-travelling the target.

Next, I tried mapping the 8000 counts to 7200 counts ("900 = 1000"), and that didn't work either. Now my incremental indexes were too short!

I was puzzled about why two mathematically sound approaches were failing, but also concerned about getting it done. I thought the registration method would be the answer, and called our local servo guru for advice.

Turns out the math was okay - but Bru servo drives just don't do this sort of calculation well. I stayed with the 7200 count method (600 = 30 degrees rotation)and adjusted the Home switch to a position between two nests. Programmed a Home offset to the first nest, changed my indexing move from "incremental" to "registration" and gave a registration distance equal to my home offset.

Boom, no more problem. The error per move is too low to affect the system in a single spin of the table, and is corrected every time the home/registration sensor is passed.

Thanks!

TM