55 visninger
Gå til det første ulæste indlæg

### Pedro

ulæst,
5. feb. 1999 03.00.0005.02.1999
til
Hi,

I am looking for a circuit to determine the direction of rotation of a
incremental optical encoder.

Pedro

pedr...@entelchile.net

### Tommy Lee

ulæst,
6. feb. 1999 03.00.0006.02.1999
til
On 5 Feb 1999 17:33:22 -0800, Pedro <Pe...@newsguy.com> wrote:

>Hi,
>
>I am looking for a circuit to determine the direction of rotation of a
>incremental optical encoder.
>
>
>Pedro

I could implement this with software very easily.

I tried to be as vague as you were

### Stephen Mellor

ulæst,
6. feb. 1999 03.00.0006.02.1999
til
Pedro ...

> I am looking for a circuit to determine the direction of rotation of a
> incremental optical encoder.

Been a while since I did this, but if memory serves....

Call your two signals A and B,

A rising edge on A while B is low indicates one direction. A rising edge
on A while B is high indicates the opposite direction.

Or

A rising edge on B while A is high indicates one direction. A rising edge
on B while A is low indicates the opposite direction.

One direction...

-------- -------- --------
A | | | | | |
---- -------- -------- ----

-------- -------- --------
B | | | | | |
-------- -------- -------- ----

The opposite direction...

-------- -------- --------
A | | | | | |
-------- -------- -------- ----

-------- -------- --------
B | | | | | |
---- -------- -------- ----

Simple flip-flops will suffice.

However, it's not quite that easy - consider the possibility of the
encoder being stopped right on the edge of A, and vibration causes the
edge to keep toggling - this would cause false triggering.

IIRC the old Atari ST mouse suffered from this - you could sometimes,
while the mouse was stationary, see the cursor zip off in one direction.

The problem...

- - -
A | | | | | |
-------- - - ----

B
-----------------------

To get around this you have to watch both A and B for edges, and not
allow an edge from one unless you've had an edge from the other.

Hmmm. Hope that makes some sort of sense.

*Mel!*

Project engineer and bum.

### Frank Bemelman

ulæst,
6. feb. 1999 03.00.0006.02.1999
til
Pedro heeft geschreven in bericht
<79g652\$h...@edrn.newsguy.com>...
>Hi,

>
>I am looking for a circuit to determine the direction of
rotation of a
>incremental optical encoder.
>
>
>Pedro

Only direction ? You could use a d-flipflop (4013) and
connect the A signal to clock, and B signal to datainput. Q
output gives you the direction. If you also want to up/down
count the pulses, take a look at HTM2000 from Hewlett
Packard.

Met vriendelijke groeten,
Frank Bemelman
(reageren per email ? verwijder dan de 'x' uit mijn

### Frank Bemelman

ulæst,
6. feb. 1999 03.00.0006.02.1999
til
Tommy Lee heeft geschreven in bericht

>On 5 Feb 1999 17:33:22 -0800, Pedro <Pe...@newsguy.com>
wrote:
>>I am looking for a circuit to determine the direction of
rotation of a
>>incremental optical encoder.
>
>I could implement this with software very easily.

I am not too sure about encoders as being very easy to deal
with in software.

Suppose you have an encoder with 360 pulses per revolution,
and it is running at 1200 rpm. How would you implement that
in software ? Can you show us some code ?

ulæst,
6. feb. 1999 03.00.0006.02.1999
til

(1200*360)/60 = 7200Hz that should be no problem, I have
no code to show, but if you really want it I'll write some :)

--Lasse
--___--_-_-_-____--_-_--__---_-_--__---_-_-_-__--_----
Lasse Langwadt Christensen, MSEE (to be in 1999)
Aalborg University, Department of communication tech.
Applied Signal Processing and Implementation (ASPI)
http://www.kom.auc.dk/~fuz , mailto:lang...@ieee.org

ulæst,
6. feb. 1999 03.00.0006.02.1999
til
Stephen Mellor wrote:
>
> Pedro ...

>
> > I am looking for a circuit to determine the direction of rotation of a
> > incremental optical encoder.
>
> Been a while since I did this, but if memory serves....
>
> Call your two signals A and B,
>
snip,how it work and the easy way :)

>
> Simple flip-flops will suffice.
>
> However, it's not quite that easy - consider the possibility of the
> encoder being stopped right on the edge of A, and vibration causes the
> edge to keep toggling - this would cause false triggering.
>
yeah the simple way is more or less useless unless it's for
contineous rotation, where you just want speed and direction

snip

> To get around this you have to watch both A and B for edges, and not
> allow an edge from one unless you've had an edge from the other.
>
> Hmmm. Hope that makes some sort of sense.
>
> *Mel!*
>
> Project engineer and bum.

the usual way of doing it and probably the best is to make it
synchronous,
(that also has the advantage that you know when the counter can change)

"sample" A and B at a fixed rate, at each a new sample compare
the new_AB, with the previous_AB, and afterward you update previous_AB

case previous_AB

when "00"
if new_AB = "01"
count +=1
elsif new_AB = "10"
count -=1
else
count = count
endif
when "01"
if new_AB = "11"
count +=1
elsif new_AB = "00"
count -=1
else
count = count
endif
when "11"
if new_AB = "10"
count +=1
elsif new_AB = "01"
count -=1
else
count = count
endif

when "10"
if new_AB = "00"
count +=1
elsif new_AB = "11"
count -=1
else
count = count
endif

previous_AB = new_AB

ulæst,
6. feb. 1999 03.00.0006.02.1999
til Pedro
> I am looking for a circuit to determine the direction of rotation of a
> incremental optical encoder.

Check US Digital's LS7166 (www.usdigital.com)

Ashok

### Robert Scott

ulæst,
6. feb. 1999 03.00.0006.02.1999
til

a multi-stage shift register to filter out high frequency
noise which could result in lost or extra counts. If noise
is at all an issue, get a dedicated quadrature chip.

Bob Scott
Ann Arbor, Michigan (email: rscott (at) wwnet (dot) net )
(My automatic return address is intentionally invalid.)

### Frank Bemelman

ulæst,
6. feb. 1999 03.00.0006.02.1999
til
Lasse Langwadt Christensen heeft geschreven in bericht
<36BC929F...@kom.auc.dk>...

>Frank Bemelman wrote:
>> Suppose you have an encoder with 360 pulses per
revolution,
>> and it is running at 1200 rpm. How would you implement
that
>> in software ? Can you show us some code ?
>
>(1200*360)/60 = 7200Hz that should be no problem, I have
>no code to show, but if you really want it I'll write some
:)

I am still not convinced what an economical software
solution would look like. Once I tried it with signal A fed
through an exor gate, triggering a negative edge sensitive
interrupt. The first thing the interrupt would do, was to
toggle an output connected to the other input of the exor
gate, effectively making the interrupt input sensitive to a
positive edge. It did work to some extent, but odd
oscillations while the encoder was stopped, messed things
up. A safer way is to use timed interrupts, but that is
rather cpu-time-expensive for a small micro. I guess I just
hate encoders ;-)

Oth, digital pots are not too bad, as long as they are used
for man/machine interface, to set parameters etc. Does not
hurt too much, if you loose a step or two.

Actually I was hoping for that revealing answer that
encoders indeed are simple to use...

### Alan Inness

ulæst,
7. feb. 1999 03.00.0007.02.1999
til
Hi, If you need a hardware solution, use any TTL up/dwn counter, phase A
would be the count and phase B would be input to the direction pin. If
you require the reverse count, switch the A & B inputs. If the encoder
is a differential type i.e. A. /A. B. /B. use two signals only. either A
& B or /A & /B.
Regards
Al I.

Pedro wrote:
>
> Hi,

>
> I am looking for a circuit to determine the direction of rotation of a
> incremental optical encoder.
>

ulæst,
7. feb. 1999 03.00.0007.02.1999
til
Alan Inness wrote:
>
> Hi, If you need a hardware solution, use any TTL up/dwn counter, phase A
> would be the count and phase B would be input to the direction pin. If
> you require the reverse count, switch the A & B inputs. If the encoder
> is a differential type i.e. A. /A. B. /B. use two signals only. either A
> & B or /A & /B.
> Regards
> Al I.
>

one problem with that is that it will be very sensitive to noise
or the encoder being stopped on an edge

> Pedro wrote:
> >
> > Hi,
> >
> > I am looking for a circuit to determine the direction of rotation of a
> > incremental optical encoder.
> >
> >
> > Pedro
> >
> > pedr...@entelchile.net

ulæst,
7. feb. 1999 03.00.0007.02.1999
til
Robert Scott wrote:
>
snip

> >
>
> a multi-stage shift register to filter out high frequency
> noise which could result in lost or extra counts. If noise
> is at all an issue, get a dedicated quadrature chip.
>
> Bob Scott
> Ann Arbor, Michigan (email: rscott (at) wwnet (dot) net )
> (My automatic return address is intentionally invalid.)

yes sampling a few times and doing a majority vote can help alot
and that also goes for software uarts, a real quadrature chip is
of course great but they are not exactly cheap.

ulæst,
7. feb. 1999 03.00.0007.02.1999
til
Frank Bemelman wrote:
>
> Lasse Langwadt Christensen heeft geschreven in bericht
> <36BC929F...@kom.auc.dk>...
> >Frank Bemelman wrote:
> >> Suppose you have an encoder with 360 pulses per
> revolution,
> >> and it is running at 1200 rpm. How would you implement
> that
> >> in software ? Can you show us some code ?
> >
> >(1200*360)/60 = 7200Hz that should be no problem, I have
> >no code to show, but if you really want it I'll write some
> :)
>
> I am still not convinced what an economical software
> solution would look like. Once I tried it with signal A fed
> through an exor gate, triggering a negative edge sensitive
> interrupt. The first thing the interrupt would do, was to
> toggle an output connected to the other input of the exor
> gate, effectively making the interrupt input sensitive to a
> positive edge. It did work to some extent, but odd
> oscillations while the encoder was stopped, messed things
> up.

looking for just an edge is bound to fail if the encoder can be stopped
close to a rising edge

> A safer way is to use timed interrupts, but that is
> rather cpu-time-expensive for a small micro.

yes sampling at a fixed rate making everything synchronous will be much
better and you should look at "states" instead of edges, it could become
cpu intensive, but software uarts are used all the time, a quadrature
decoded
will not be that much different

>I guess I just
> hate encoders ;-)
>
> Oth, digital pots are not too bad, as long as they are used
> for man/machine interface, to set parameters etc. Does not
> hurt too much, if you loose a step or two.
>
> Actually I was hoping for that revealing answer that
> encoders indeed are simple to use...
>
> Met vriendelijke groeten,
> Frank Bemelman
> (reageren per email ? verwijder dan de 'x' uit mijn

a trick that could perhaps be used it that if you do
a = A, b = A xor B

then the grey coded sequence AB=00,01,11,10 becomes the binary
sequence ab=00,01,10,11. So in pseudocode something like this
in a timer interrupt may work

old_AB = new_AB % update old_AB
new_AB = A,xor(A,B) % read A,B convert to binary

if new_AB != old_AB % changed ?
countup = old_AB + 1 % should be modulo 4 !!!
countdown = old_AB - 1 % should be modulo 4 !!!
if new_AB = countup % count up ?
count += 1
elsif new_AB = countdown % count down ?
count -= 1
else
ERROR!!!!
endif
endif

### Alex Lait

ulæst,
7. feb. 1999 03.00.0007.02.1999
til
says...

> > I am looking for a circuit to determine the direction of rotation of a
> > incremental optical encoder.
>
> Check US Digital's LS7166 (www.usdigital.com)
>
> Ashok
>

For a school project I designed a quadrature decoder/counter for a
milling machine digital readout. The decoder is implemented in a Lattice
ispLSI1016 CPLD. In small quantities the Lattice chips are around \$6 for

My design has a de-glitching filter, 4X quadrature decoder, 16bit up/down
counter, and an 8bit microprocessor interface. The de-glitching filter
removes input pulses that are shorter than 2 clock cycles. 4X quadrature
decoding counts each edge of the input, giving 4 times the resolution
(I.e. 360 line per inch tape gives 1440 counts per inch). The 16bit
up/down counter means that you just have to pole the chip often enough
that the counter has not rolled over.

With the 80MHz speed grade CPLDs, you can clock the system up to 12MHz.
Using an 8MHz clock, I estimate that the quadrature signal should be able
to run at 1MHz before pulses will be missed.

If people are interested, I will put up the source code (ABLE) on my web
site.

Alex Lait

### Frank Bemelman

ulæst,
7. feb. 1999 03.00.0007.02.1999
til
Alan Inness heeft geschreven in bericht
<36BDDA...@escape.ca>...

>Hi, If you need a hardware solution, use any TTL up/dwn
counter, phase A
>would be the count and phase B would be input to the
direction pin.

If the encoder vibrates while stopped, it is possible that
phase A goes high-low for a couple of times, and the count
is not accurate anymore.

### Frank Bemelman

ulæst,
7. feb. 1999 03.00.0007.02.1999
til
Lasse Langwadt Christensen heeft geschreven in bericht
<36BDFEC9...@kom.auc.dk>...

>yes sampling at a fixed rate making everything synchronous
will be much
>better and you should look at "states" instead of edges, it
could become
>cpu intensive, but software uarts are used all the time, a
>decoded will not be that much different

True, but even with modest speeds it already requires a
rather high interrupt rate. It would be nice if a chip
existed that you could load with a table of interrupt
vectors for certain encoder positions. 32 entrys would be
fine, if need be, one could add a chip or two.

>a trick that could perhaps be used it that if you do
>a = A, b = A xor B
>
>then the grey coded sequence AB=00,01,11,10 becomes the
binary
>sequence ab=00,01,10,11. So in pseudocode something like
this
>in a timer interrupt may work
>
>old_AB = new_AB % update old_AB
>new_AB = A,xor(A,B) % read A,B convert to
binary
>
>if new_AB != old_AB % changed ?
> countup = old_AB + 1 % should be modulo 4 !!!
> countdown = old_AB - 1 % should be modulo 4 !!!
> if new_AB = countup % count up ?
> count += 1
> elsif new_AB = countdown % count down ?
> count -= 1
> else
> ERROR!!!!
> endif
>endif

More or less the same as my *standard* encoder routine,
where NewENcoderAB contains channel A and B in its least
significant bits:

if(NewEncoderAB != OldEncoderAB)
{
OldEncoderAB <<= 1;
OldEncoderAB ^= NewEncoderAB;
if(OldEncoderAB & 0x2)
{ EncDirection = REVERSE;
enc_raw--;
}
else
{ EncDirection = FORWARD;
enc_raw++;
}
OldEncoderAB = NewEncoderAB;
}

For readabilty in C, but I rewrote this in assembler after
it proved to be okay ;-)

### Alan Inness

ulæst,
7. feb. 1999 03.00.0007.02.1999
til
Frank Bemelman wrote:
>
> Alan Inness heeft geschreven in bericht
> <36BDDA...@escape.ca>...
> >Hi, If you need a hardware solution, use any TTL up/dwn
> counter, phase A
> >would be the count and phase B would be input to the
> direction pin.
>
Not true, if the circuit uses an edge counter when the encoder
oscillates back and forth the direction level is also reversed, draw it
out and you will see. This is how just about all CNC machine tools use
this method.
Al Inness.

> If the encoder vibrates while stopped, it is possible that
> phase A goes high-low for a couple of times, and the count
> is not accurate anymore.
>

### Allan Herriman

ulæst,
8. feb. 1999 03.00.0008.02.1999
til
Pedro,
can look it up in dejanews.

Subject: How to write a motion decoder & a counter
Author: leslie.yip
Date: 1998/07/31
Forums: comp.arch.embedded, comp.vhdl.com, sci.electronics.design

of the direction discriminator (mostly from Lasse - Hi!).

Regards,
Allan.

On 5 Feb 1999 17:33:22 -0800, Pedro <Pe...@newsguy.com> wrote:

>Hi,

>I am looking for a circuit to determine the direction of rotation of a
>incremental optical encoder.

>Pedro

### Frank Bemelman

ulæst,
8. feb. 1999 03.00.0008.02.1999
til
Alan Inness heeft geschreven in bericht
<36BE39...@escape.ca>...

>Frank Bemelman wrote:
>>
>> Alan Inness heeft geschreven in bericht
>> <36BDDA...@escape.ca>...
>> >Hi, If you need a hardware solution, use any TTL up/dwn
>> counter, phase A
>> >would be the count and phase B would be input to the
>> direction pin.
>>
>Not true, if the circuit uses an edge counter when the
encoder
>oscillates back and forth the direction level is also
reversed, draw it
>out and you will see. This is how just about all CNC
machine tools use
>this method.
>Al Inness.

Imagine the encoder stops right behind a edge that clocked
the counter. Next move, it goes a little bit backwards, and
the clock falls back again (but does not clock the counter,
nor does the other channel - direction - change). Now it
moves forward again, and there is your second clock pulse,
and a false count is the result. In CNC machines it might be
allright to do it this way, because the gears won't allow
the motor to move when it is stopped, and the fotocel
amplifier has a hysteris to prevent oscillations. If you
have a more or less free moving motor/encoder, without
brakes etc, a simple up/down counter is too risky if an
absolute accurate count is needed. And I did draw it out, so
I know I am not mistaken ;-)

### Pedro

ulæst,
8. feb. 1999 03.00.0008.02.1999
til
Hello,

Thank you to the newsgroup. After read so many opinions I decided for the US
Digital's LS7166. It is very smart IC and cheaper than HP equivalent,

Best regards to everybody,

Pedro Mardones

ulæst,
10. feb. 1999 03.00.0010.02.1999
til
Frank Bemelman wrote:
>
>snip

>
> More or less the same as my *standard* encoder routine,
> where NewENcoderAB contains channel A and B in its least
> significant bits:
>
> if(NewEncoderAB != OldEncoderAB)
> {
> OldEncoderAB <<= 1;
> OldEncoderAB ^= NewEncoderAB;
> if(OldEncoderAB & 0x2)
> { EncDirection = REVERSE;
> enc_raw--;
> }
> else
> { EncDirection = FORWARD;
> enc_raw++;
> }
> OldEncoderAB = NewEncoderAB;
> }
>
> For readabilty in C, but I rewrote this in assembler after
> it proved to be okay ;-)

>
> Met vriendelijke groeten,
> Frank Bemelman
> (reageren per email ? verwijder dan de 'x' uit mijn

yes (damn, how could I miss something so obvious :) )

looking at the diagonal

0 0 1 1 0 0 1 1 0 0 1 1 0
/ / / / / \ \ \ \ \ \
0 1 1 0 0 1 1 0 0 1 1 0 0

in one direction it's alway different, the other always the same

so something like this should work

clk-+----------+
| .----. | .----. _
A >---|D Q|-+---|D Q|-----\\ \__
+-|> | | +-|> | +-//_/ |
| '----' | | '----' | |
| +------------+ |
| | | _ |
| +--------------\\ \__________ direction
| | +--//_/
| | | | __
| .----. | .----. | _ +-\ \__ count
B >---|D Q|-+---|D Q|--+--\\ \_.--/__/
+-|> | | +-|> | +-//_/
'----' | '----' |
+------------+

### James Meyer

ulæst,
10. feb. 1999 03.00.0010.02.1999
til
On Wed, 10 Feb 1999 07:39:34 GMT, Lasse Langwadt Christensen
<f...@kom.auc.dk> wrote:

>so something like this should work
>
>clk-+----------+
> | .----. | .----. _
>A >---|D Q|-+---|D Q|-----\\ \__
> +-|> | | +-|> | +-//_/ |
> | '----' | | '----' | |
> | +------------+ |
> | | | _ |
> | +--------------\\ \__________ direction
> | | +--//_/
> | | | | __
> | .----. | .----. | _ +-\ \__ count
>B >---|D Q|-+---|D Q|--+--\\ \_.--/__/
> +-|> | | +-|> | +-//_/
> '----' | '----' |
> +------------+

Indeed. I built something very similar to that many years ago
completely from 7400 TTL NAND gates. Cross-coupled some for the flip-flops
and connected some more of them into XOR gates which with an RC delay in one
input derived the clock signal from the A and B inputs themselves.

Jim

### Frank Bemelman

ulæst,
10. feb. 1999 03.00.0010.02.1999
til
Lasse Langwadt Christensen heeft geschreven in bericht
<36C137B5...@kom.auc.dk>...

>looking at the diagonal
>
>0 0 1 1 0 0 1 1 0 0 1 1 0
> / / / / / \ \ \ \ \ \
>0 1 1 0 0 1 1 0 0 1 1 0 0
>
>in one direction it's alway different, the other always
the same
>
>so something like this should work
>
>clk-+----------+
> | .----. | .----. _
>A >---|D Q|-+---|D Q|-----\\ \__
> +-|> | | +-|> | +-//_/ |
> | '----' | | '----' | |
> | +------------+ |
> | | | _ |
> | +--------------\\ \__________ direction
> | | +--//_/
> | | | | __
> | .----. | .----. | _ +-\ \__ count
>B >---|D Q|-+---|D Q|--+--\\ \_.--/__/
> +-|> | | +-|> | +-//_/
> '----' | '----' |
> +------------+
>

This is going too fast for me - but I have copied this
message to my *forever* map. I'll give it a try when I have
a bit of time. With this little circuit I could trigger
interrupts, and read the direction during the interrupt...
oops... perhaps an extra latch to disable the sampling
clock, and reset that latch at the end of the interrupt. I
have to think about it ;-) But it looks great.

ulæst,
13. feb. 1999 03.00.0013.02.1999
til
Frank Bemelman wrote:
>
>
snip

> >
>
> This is going too fast for me - but I have copied this
> message to my *forever* map. I'll give it a try when I have
> a bit of time. With this little circuit I could trigger
> interrupts, and read the direction during the interrupt...
> oops... perhaps an extra latch to disable the sampling
> clock, and reset that latch at the end of the interrupt. I
> have to think about it ;-) But it looks great.
>

You could do that but, you'll still have to able to service
interrupts at the full rate so in a real time app. it migth
not be a great advantage, beside the few instructions you
save in the ISR, and if it's for a control system you'll need
the counting is done entirely in HW

ulæst,
13. feb. 1999 03.00.0013.02.1999
til
James Meyer wrote:
>
snip

> >
>
> Indeed. I built something very similar to that many years ago
> completely from 7400 TTL NAND gates. Cross-coupled some for the flip-flops
> and connected some more of them into XOR gates which with an RC delay in one
> input derived the clock signal from the A and B inputs themselves.
>
> Jim

another way could be to invert the clock, AND it with 'count' and
use that to clock the a counter, that way the 'direction' has 1/2
a clock cycle to stabilize before the rising edge on the clock to
the counter
_ _ _ _
CLK _| |_| |_| |_|
_ _ _ _ _
/CLK |_| |_| |_| |_|

___
count _____/ \_______
_
count&/CLK _______| |_______

### Sudha

ulæst,
31. dec. 2004 03.01.4331.12.2004
til
Hi Alex,

We are working on optical incremental encoder in one of my
assignment.can you please give some guidance on that and i also request
to send me the code for quadrature encoder for my reference.
regards,

S.RANGA REDDY

### Paul Burke

ulæst,
31. dec. 2004 07.09.5731.12.2004
til

Don't know who Alex is, but there's VHDL source in the OpenCores archive.

Paul Burke

### James Meyer

ulæst,
31. dec. 2004 08.38.3231.12.2004
til
On Fri, 31 Dec 2004 12:09:57 +0000, Paul Burke <pa...@scazon.com> wroth:

Hi Paul,

Sudha was posting through the new Google Group fiasco. He saw a message
from Alex, which was posted God knows how long ago, and thought that Alex would
be forever watching for replies to that particular message. Or maybe, God
forbid, Sudha thought that his message would be delivered directly to Alex.

Google is going to kill the Usenet groups if they don't quit what
they've started with their new abortion of a news reader.

Jim

### Rich Webb

ulæst,
31. dec. 2004 14.16.3431.12.2004
til
On Fri, 31 Dec 2004 13:38:32 GMT, James Meyer <jme...@nowhere.net>
wrote:

From the Google corporate relations page

"Our informal corporate motto is "Don't be evil."

Guess they left out the part about "Don't be greedy."

--
Rich Webb Norfolk, VA

Svar alle
Svar forfatteren
Videresend
0 nye indlæg