Re: Linear encoder and rotary motor servo

Posted by: "Stephen Wille Padnos" <mailto:spadnos@...?Subject=
Re%3A%20Linear%20encoder%20and%20rotary%20motor%20servo>spadnos@...
<http://profiles.yahoo.com/swpadnos>swpadnos



Tue Jul 31, 2007 4:33 pm (PST)

<mailto:elliot%40hitide.com>elliot@... wrote:

>>This has been discussed before: a linear encoder combined with a rotary
>>motor and some sort of rotary motion/linear motion conversion. The
>>consensus has been that this is a bad idea because play in the rotary/linear
>>motion conversion will cause the servo to go wild, hunting and vibrating.
>>
>>

>That's likely to be true in a machining environment. The cutter causes
>an oscillation in force, since there's more force when a tooth is
>engaged than when there isn't. The PID loop for the motor will have
>some oscillation - even if this is just the "singing" between encoder
>counts. If the gain is too high (gives you a nice stiff machine) and
>there's too much backlash or you hit the natural frequency of the belt
>or something, then boom - you get oscillation.
>

My experience is that this tooth-to-tooth force variation is higher than the
response frequency of the servo system. The variation in force resulting
from variations in the speed and depth of cut are more significant to
the servos, and these fall within the response frequency of the servo
system -- and are caused by variations in the work-to-cutter position
which is being forced by the servos.

>>I was convinced that this was so until I took apart a inkjet printer
>>yesterday and found that it had a rotary motor and a linear encoder. The
>>rotary to linear motion bit is a cogged belt.

This is the most common way to implement the side-to-side motion of
the ink jet print heads. HP, Lexmark, Kodak, and Canon (at least) use a
belt to couple the motor to the print head carrier.

>The load on an inkjet print drive mechanism is nearly constant, and they
>don't hold position - they need to maintain velocity.

The load on the inkjet print drive, as measured by the motor torque, is not at
all constant. The print head carrier is accelerated at very high
rates, both to
bring it up to the desired printing velocity, and to brake it afterward.

>They need
>position feedback so that the ink drops can be clocked out to the jets,
>but that's easily done. you can tune the latency as well - the older
>inkjets had a test mode where they would print some dashes with
>alternate jets when moving in one direction, then would do the same in
>reverse. You would then change some parameter until the print looked
>nice and even.

I can't speak for any specific printer manufacturers, but my experience
is that the dominant factor determining alignment is not the mechanical
system, but is rather the electrical and ballistic system of forming ink dots
and moving them to the paper. Both of these impose latencies which
depend on the physics (and unit-to-unit variation) in the print heads.

>The position encoder only needs to know that you're in
>the same place going one direction or the other - it doesn't need to
>know exactly where that is, since that's takes care of with the software
>offsets (and there's usually an index mark on the encoder strip as well).

I haven't seen encoder strips with an index mark (although I certainly
haven't seen them all). Usually there is an independent mechanism used
to establish the reference position.

>>Since millions are of these were made, it clearly works. Is the common
>>problem with servos of this sort caused by backlash between a screw and nut?

The sources of backlash could include:
slippage between the toothed pulley on the motor and the belt
stretching of the belt
flexing of the support frame connecting the motor with the head carrier

Unlike more complex ball-screw drives, there isn't any point where the must
be backlash for the parts to move.

>See above - that also takes care of backlash.
>
>>The encoder grating pitch is 0.0055 inch, so by detecting all edges they
>>could get the precision they need.

I'm more familiar with 0.0067 inch pitch belts, which are a 150 line per inch
grating.

>>The motor cogs less than some DC motors its size, but still is not exactly
>>smooth when turned by hand.

These servos aren't being used to maintain position. There are used to
know position while maintaining a target velocity. The motor cogging at the
desired carrier speeds may be higher than the servo response frequency.
It could be a problem at lower speeds, such as "zero" speed for setting a
precise position. If you were writing your own servo loop, though, I would
think it could be accounted for, perhaps as a position dependant gain
parameter.

>>Does anyone know if this 0.0055"/4 is about the limit of what can be done
>>with a cogged belt? It would be a really neat way to make a hexapod.

The problem may be more in the limits of the encoder resolution than in the
belt. If the encoder line pitch were increased too much, then dust particles
and axis skew between the strip and the sensor could become problems.

>>
>>regards-
>>Elliot
>>
>>
>There's also dual-loop control, where you have an encoder on the motor
>and a scale on the table. The encoder is used as the feedback to the
>motor control PID, and the linear scale is used as the final position
>feedback for the higher level position loop. I think the motor encoder
>is used for the most part, but the scale allows minor corrections.
>Also, since the motor velocity/position loop uses the rotary encoder,
>there's no issue with oscillation.
>
>Hopefully, someone who understands dual-loop better can fill in the gaps
>(or replace what I've written, as the case may be :) )
>- Steve

This sounds like the dual loops where there is tachometer (velocity)
feedback from the motor, and position feedback from the table.

-- Carl


cmm@...
www.foxkid.net


[Non-text portions of this message have been removed]