Question about anti-backlash gears

[louiecski]

Hello all,

I've recently attempted to field an antenna rotator system and have been stalled by what appears to be a backlash problem. I currently have a closed-loop feedback in place using an optical encoder. The encoder is driven via a 60-tooth, 24 DP, anti-backlash gear mated with a normal. 60-tooth, 24 DP spur gear directly coupled to the load. Having done some accuracy testing, it looks like we're seeing as much as 0.5 degrees of over-travel in this system whenever it reverses direction. This would be consistant with 0.5 degrees of lost motion at the encoder (thus the servo drive "thinks" it has to travel 0.5 degrees further to meet the position). Since this is my first time using anti-backlash gears, I have to ask if any more experienced people out here have any suggestions?

 

[eromlignod]

Wow. Half a degree is a lot. That's 1/12th of an entire tooth pitch. It sounds like your anti-backlash gear isn't working at all.

Have you taken a look at the spring(s) to see if it is broken, missing, or disconnected? Also, the two plates of the anti-backlash gear should rotate freely against each other. If they stick, you may need to clean and/or lubricate them.

Don
Kansas City

 

[MikeHalloran]

What's the resolution of the encoder?



Mike Halloran
Pembroke Pines, FL, USA

 

[Heckler]

What is your encoder pulse resolution?
What is your gear ratio?

I was a design lead for a drive system for waffer handling within a PVD (Physical Vapor Deposition) equipment. This turned out to be a high precision gearhead 3 arc-seconds. This was driven by the robotic end-effectors needing a near absolute position for waffer pickup.Todays, motion control electronics can then be programmed to correct error in position.....ie backlash can be compensated for electronically by using an external absolute encoder for comparison to the shaft encoder.

it appears that something else is wrong with your system. I would consult with a motion control expert.

Best Regards,

Heckler
Sr. Mechanical Engineer
SW2007 SP 2.0 & Pro/E 2001
Dell Precision 370
P4 3.6 GHz, 1GB RAM
XP Pro SP2.0
NVIDIA Quadro FX 1400
o
_`\(,_
(_)/ (_)

Never argue with an idiot. They'll bring you down to their level and beat you with experience every time.

 

[louiecski]

Thanks for the prompt replies, I'll answer some of the resulting questions:

The encoder is using SSI interface and is currently giving us 32770 steps per revolution. Our motion control board uses a non-floating point processor, so we sometimes lose a few counts doing the math, but a few counts is well within our error tolerance and is nowhere near enough to cause this kind of error.

The gear springs are in good position, the halves do slide across each other easily. Prior to engaging them, I tried to vary the amount of "pre-load" and it seemed like 1-tooth offset felt like too little and I wasn't able to easily do more than 2 teeth of offset. So, the anti-backlash gear is preloaded with a two-tooth offset (not sure if this is the correct terminology - but I mean that the two halves the anti-backlash gear are phased two teeth apart to preload the springs).

The ratio of the gears driving the encoder is 1:1 (60 teeth:60 teeth).

Our previous rotator did not have closed-loop feedback and used a homing-sequence and limit switches to find "home" and then used the servo resolver to keep track of all motion from that point. We had to implement a backlash compensation routine in the code to compensate for the planetary reducer's backlash and that worked reasonably well. Since we are not using limit switches or a homing sequence this time, we aren't able to use the backlash compensation because every time we cycle power, we have a 50/50 chance of doubling the error instead of removing it - depending on which direction the rotator last traveled.

 

[MikeHalloran]

I'm conjecturing that bit 5 or maybe bit 6 of the encoder is 'dead', i.e., wire broken, dirt in optical path, source or receiver dead, etc.



Mike Halloran
Pembroke Pines, FL, USA

 

[sreid]

Is it possible that the servo gain is so low that you have a significant "Stiction" deadband?

 

[GregLocock]

32768 is more likely. not a big error, in context

Cheers

Greg Locock

Please see FAQ731-376 for tips on how to make the best use of Eng-Tips.

 

[zekeman]

You are looking at a whopping .008" of gear backlash acting like no antibacklash in reverse. Why dont you test this by hand rotating the encoder shaft while holding the antenna fixed looking for changes at the encoder readout. It could also be as simple as the coupling of the encoder to its gear.

 

[chicopee]

Could it be possible that you may have different pressure angles between the driver and driven gears?

 

[dimjim]

Wonder if you have a loose setscrew
somewhere. The error seems not possible
without something else wrong other than
the anti backlash pinion.

 

[WoodyPE]

If the problem isn't consistently repeatable, then it's probably a mechanical problem.

If it is consistent then it's probably electrical.

I have a lot of expertise with gearing, but I'm not your best servo-mechanism person -- though probably up to par for a mechanical engineer.

We have an application where there weren't enough encoder positions (not accurate enough)to get consistent results, but that's already been covered. Actually there was more involved than just the positions, it's seems there was response speed and compensation involved as well. The processor couldn't keep up with it. my 2 cents.

http://www.angelfire.com/planet/gadgetforum/index.html

 

[louiecski]

Thanks again for all the suggestions:

The problem is VERY repeatable, and we haven't ruled out an electrical problem. Our servo/software guru has been "playing" with the drive tuning, but that doesn't seem to make much difference except in how much time it takes to settle down after a move. One thought that HAS occurred is that we originally ordered the encoders with a 13 bit signal (8192 counts), and decided that a 15 bit would work better for our needs (Greg is correct - it is actually 32768 counts now). The encoder vendor did change one of them for us but our software expert discovered a way to change it externally by changing the signal being sent to the encoder. We're going to do some testing tomorrow like what zekeman is suggesting.

Thanks again

 

[WoodyPE]

Good luck Louiecski,

That was only a general rule of thumb I gave you. In the end you will probably find 2 to 3 problems layered under the onion skin. Probably more electrical but possibly a mechanical interaction as well -- my 2 cents as a product assurance test engineer (in a previous life) for monochrome laser printers.

http://www.angelfire.com/planet/gadgetforum/index.html

 

[WoodyPE]

PS, when I say "electrical", I mean "programming" as well.

http://www.angelfire.com/planet/gadgetforum/index.html