quadrature encoder

On Apr 27, 6:19=A0am, Spehro Pefhany <speffS...@interlogDOTyou.knowwhat>
wrote:
>
> If you only care about speed and not direction, one edge on one channel m=
ay be sufficient.

 A purist could argue, that for position, all edges should be used,
(you can easily discard precision later) but for speed readings, only
the same edges should be considered, as quadrature encoders are NOT
guaranteed to have 50.00% duty cycles (or even 90.00' alignment).

-jg

"princekcs" <princekcs@n_o_s_p_a_m.gmail.com> wrote in message 
news:Lp6dnSYNcdAENUjWnZ2dnUVZ_jidnZ2d@giganews.com...
> why is it necessary to clock on rising and falling edge when reading a
> quadrature encoder?

Because if the encoder changes direction, you will clock on the
wrong edge and slowly lose registration.

Try it for yourself as a paper exercise; keep changing direction
over a very few steps and watch your position counter slowly drift!

And it doesn't have to be a deliberate change of direction, either. 
Torsional
vibration when the encoder is sitting on one of the edges will cause a
steady creep in one direction.

Let me try to phrase that a little better.

Let us suppose that you are operating bi-directionally, clocking
from the rising edge, and the encoder is sitting over what would be
your falling edge. Each vibration backwards will give you what appears
to be a rising edge, causing a downwards count, but each vibration forward
will not be registered because it is sitting on the falling edge which you 
are
ignoring.

And therby hangs a tale! In a recent project I wa controlling a stepper 
motor
with such an encoder and was losing accuracy for the reasons stated above!

The algorithm to avoid the problem comes from a much larger state machine 
than
is normally used ... you have to consider what you are going to do if you 
receive
two opposite transitions from the same input without there being a 
transition on the
other input.

-jg wrote:
> On Apr 27, 6:19 am, Spehro Pefhany<speffS...@interlogDOTyou.knowwhat>
> wrote:
>>
>> If you only care about speed and not direction, one edge on one channel may be sufficient.
>
>   A purist could argue, that for position, all edges should be used,
> (you can easily discard precision later) but for speed readings, only
> the same edges should be considered, as quadrature encoders are NOT
> guaranteed to have 50.00% duty cycles (or even 90.00' alignment).

Machine-tool grade encoders had damn well better be
guaranteed to have accurate angular alignment.

On Tue, 27 Apr 2010 10:23:50 -0700, Jim Stewart <jstewart@jkmicro.com>
wrote:

>-jg wrote:
>> On Apr 27, 6:19 am, Spehro Pefhany<speffS...@interlogDOTyou.knowwhat>
>> wrote:
>>>
>>> If you only care about speed and not direction, one edge on one channel may be sufficient.
>>
>>   A purist could argue, that for position, all edges should be used,
>> (you can easily discard precision later) but for speed readings, only
>> the same edges should be considered, as quadrature encoders are NOT
>> guaranteed to have 50.00% duty cycles (or even 90.00' alignment).
>
>Machine-tool grade encoders had damn well better be
>guaranteed to have accurate angular alignment.

What do you reckon the accuracy of quadrature is? 

Here's a typical Renishaw read head datasheet: 

http://resources.renishaw.com/download/%28a76a7e13ca474c538f1ff1f9e301418b%29?lang=en&inline=true

The only hint I see is a 4:1 "safety factor" on the counter clock
frequency max. 

Spehro Pefhany wrote:
> On Tue, 27 Apr 2010 10:23:50 -0700, Jim Stewart<jstewart@jkmicro.com>
> wrote:
>
>> -jg wrote:
>>> On Apr 27, 6:19 am, Spehro Pefhany<speffS...@interlogDOTyou.knowwhat>
>>> wrote:
>>>>
>>>> If you only care about speed and not direction, one edge on one channel may be sufficient.
>>>
>>>    A purist could argue, that for position, all edges should be used,
>>> (you can easily discard precision later) but for speed readings, only
>>> the same edges should be considered, as quadrature encoders are NOT
>>> guaranteed to have 50.00% duty cycles (or even 90.00' alignment).
>>
>> Machine-tool grade encoders had damn well better be
>> guaranteed to have accurate angular alignment.
>
> What do you reckon the accuracy of quadrature is?
>
> Here's a typical Renishaw read head datasheet:
>
> http://resources.renishaw.com/download/%28a76a7e13ca474c538f1ff1f9e301418b%29?lang=en&inline=true
>
> The only hint I see is a 4:1 "safety factor" on the counter clock
> frequency max.

In this case I would imagine the accuracy would be
determined more by the scale than the readhead.

But that's just a guess...

On Apr 26, 1:59 pm, -jg <jim.granvi...@gmail.com> wrote:
> On Apr 27, 6:19 am, Spehro Pefhany <speffS...@interlogDOTyou.knowwhat>
> wrote:
>
>
>
> > If you only care about speed and not direction, one edge on one channel may be sufficient.
>
>  A purist could argue, that for position, all edges should be used,
> (you can easily discard precision later) but for speed readings, only
> the same edges should be considered, as quadrature encoders are NOT
> guaranteed to have 50.00% duty cycles (or even 90.00' alignment).
>
> -jg

Hi
 One problem to watch out for is to not feed an analog encoder output
in to a Schmidt triggered buffer. The problem is the levels it
switches
at eats up most of the phase margin. I've seen a couple of mouse
designs that were real flaky using a 74HC14 directly from the encoder.
As things ( led ) age, the mouse begins to fail.
 You need to amplify the signal some first such that the rise and fall
phase angles are sharper than the sine/cosine of the encoder.
 One could also use something like a comparator chip with less
positive feedback than the 74HC14 uses.
Dwight

"Magnum" <Multum.In@Parvo.invalid> wrote:
>> why is it necessary to clock on rising and falling edge when reading a
>> quadrature encoder?
>
> Because if the encoder changes direction, you will clock on the
> wrong edge and slowly lose registration.

Ah - finally, the correct answer!  It's not necessary, or event desirable, 
to clock on one of the channels, but for an application where you care about 
long-term accuracy, it's *essential* to clock on both the rising and falling 
edges of the other channel.  Magnum's explanation is exactly right!

That said, there are often times where I ignore this.  Specifically, when 
using a rotary encoder knob as a user interface input device (most car radio 
volume controls are this way, now), an occasional "lost step" isn't really 
too important, and the programming to capture the knob data is usually 
greatly simplified.  In fact, most processors can only be configured to 
interrupt on a transition in one direction, some external logic is needed to 
get both transition directions.  Polling the input is another alternative, 
usually not a very good one...
--
Mark Moulding