Searching \ for '[OT] : Dividing quadrature encoder signal' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/io/sensors.htm?key=quadrature
Search entire site for: 'Dividing quadrature encoder signal'.

Exact match. Not showing close matches.
PICList Thread
'[OT] : Dividing quadrature encoder signal'
2001\06\02@205344 by Tobie Horswill

flavicon
face
Hi all,

Has anybody ever tried to divide a quadrature signal by a given factor ? My problem is that the encoder I use generates more pulses per second than the receiving device can cope with.

Encoder:    1024 pulses per revolution of the motor shaft and the motor can spin at speeds of up to 3000rpm. This gives a little above 3,000,000 pulses per second at full speed.

Receiver:      Maximum allowable RPM = 1,500,000 / Encoder Resolution   or in this case  1,500,000/1024= 1465rpm

So I would need to divide the encoder's output roughly by a factor of 2 for the receiver to be able to follow. What's the kind of signal level coming out of an encoder ? Are they simple TTL levels? Could I simply pass the signal thru some kind of flip-flop circuit so that every two pulses from the encoder generates 1 pulse at the other end ?

BTW, I don't mind the resolution loss as the motor is already going thru a 100:1 gear-box. So I actually have 102,400 pulses per revolution at the gear-box's output...

Just being curious, anybody implemented some PIC routines to deal with quadrature encoders before ? I'm not using a PIC in this project but this IS the PICLIST after all :-)

regards,

Tobie Horswill
Ex Machina, QC, CANADA.
spam_OUTthorswilTakeThisOuTspamexmachina.qc.ca

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\06\02@214000 by Jinx

face picon face
> Encoder:    1024 pulses per revolution of the motor shaft and the motor
> can spin at speeds of up to 3000rpm. This gives a little above 3,000,000
> pulses per second at full speed.

3,000 * 1024 = 3,072,000 per MINUTE

3000rpm = 50rps = 51200 pulse/sec (= 19.53us pulse)

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2001\06\03@105000 by Tobie Horswill

flavicon
face
d'oh!

Stupid error, sorry!

I'll read what I type three times instead of twice before punching SEND from
now on...

Nevertheless, if you forget my erroneous 3,000,000 figure the result is the
same given the manufacturer's specs. I won't be able to run the encoder at
more than 1465rpm if I want the receiver to follow. So my question remains,
has anybody tried dividing a quadrature signal ?

regards,


{Original Message removed}

2001\06\03@171441 by Jinx

face picon face
> d'oh!
>
> Stupid error, sorry!
>
> I'll read what I type three times instead of twice before punching
> SEND from now on...

Nice to know someone else has off-days too ;-) And you know what
they say about checking your own work

> Nevertheless, if you forget my erroneous 3,000,000 figure the result
> is the same given the manufacturer's specs. I won't be able to run
> the encoder at more than 1465rpm if I want the receiver to follow.
> So my question remains, has anybody tried dividing a quadrature
> signal ?

The only experience I have with QEs is in mice. What you need to
preserve is the phase relationship between A and B and also detect
any reference pulse that's available for rev counting. Here's a simple
explanation of QE principle

http://www.instrument.com/support/datacq/appnote/quadratu.htm

The pulse lengths are irrelevant, only the time difference between
pulse edges matters. A micro will be able to keep up at 50kHz,
especially as a motor will not suddenly frighten it with any sudden
direction changes. Simple s/w division (or a flip-flop) would do the
job surely

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2001\06\04@174756 by Peter L. Peres

picon face
You can't divide an encoder signal, you need to build a FSM that takes
care of direction changes. Try to use a PAL or FPGA or such device. It
will work with very high speed encoders.

Peter

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body


2001\06\04@182353 by Bob Ammerman

picon face
> You can't divide an encoder signal, you need to build a FSM that takes
> care of direction changes. Try to use a PAL or FPGA or such device. It
> will work with very high speed encoders.
>
> Peter

You certainly _can_ divide an encoder signal. It just requires a fancier
state machine than a normal binary counter. :-)

One complicating factor is that the machine has to change state on both
edges of both inputs. This is rather trickier than just a 'current
state'->'next state' machine driven by a single clock (unless, of course you
drive it with a separate clock that runs faster than either input).

I suspect this could be done with a PIC12C508 at 4MHz clock and handle up to
about 100,000 Hz inputs.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


2001\06\04@204419 by Peter Wintulich

flavicon
face
The refrence to counting of each edge of the Quadriture signal I think is called x4 mode and there is PAL code for this in the AN532 on the MICROCHIP web site in the Servo Control of a DC Brush motor.

http://www.microchip.com/10/appnote/category/17cxx/misc/00532/index.htm

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservKILLspamspam.....mitvma.mit.edu with SET PICList DIGEST in the body


2001\06\04@223116 by Jeff DeMaagd

flavicon
face
----- Original Message -----
From: Bob Ammerman <EraseMERAMMERMANspam_OUTspamTakeThisOuTPRODIGY.NET>


> You certainly _can_ divide an encoder signal. It just requires a fancier
> state machine than a normal binary counter. :-)
>
> One complicating factor is that the machine has to change state on both
> edges of both inputs. This is rather trickier than just a 'current
> state'->'next state' machine driven by a single clock (unless, of course
you
> drive it with a separate clock that runs faster than either input).
>
> I suspect this could be done with a PIC12C508 at 4MHz clock and handle up
to
> about 100,000 Hz inputs.

I've made an absolute counter based but I've had trouble handling anything
beyond 50kHz input frequency (on a 4MHz chip) before it starts loosing track
of state changes and skipping states.  That's about 20 instruction cycles,
maybe I'm too inefficient?  That's the best I've been able to do.  Can
anyone say they've done better?  It certainly does the job but if I can
squeeze a few cycles then it would be of benefit to my project.  The
application note 00532 that was linked by another poster doen't reveal a
simpler or more efficient system that I can tell, actually it appears to use
a programable logic device to do that based on my interpretation of appendix
B.  That logic looks pretty hairy but I expected such.

Jeff

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...