Slowing down quadrature encoders

I have 2 motors with quadrature encoders that I can controlling using a pic16f877a. The problem is that at max rpm the encoders change faster
than the pic can count so everything goes haywire. This happens basically when I give a position command and the motor can't move at first and then the tension gets released and the motor moves very fast (kind of like winding up a spring). I need full power so limiting the pwm is not a choice. I have pcb's already made so switching to another processor is out also. What I would like is a circuit to divide the quadrature signal down but keep the phase information. I tried a couple 4017 clock dividers but they keep the same spacing between the signals in time, not in phase. Anybody have any ideas on an IC or a circuit that can do this? Thanks Ringo
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

a
Exactly how fast is that? IOW, how many ints/sec are you getting, or are you polling the encoder?

Is it, wouldn't an 18F452 basically drop right in? AFAIK it's completely pin compatible. It would certainly be faster running at 40MHz.

couple
Another PIC or two? ;-)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Actually, if you want to read quadrature, why not get a micro with a quadrature decoder built in. The DSP56F80x's in our 'Pod line can read 32 bits of hardware quadrature decoding at 40MHz input.
I think we had a discussion about this a few "which processor" discussions ago, but there aren't many micros with quadrature, so the choices are limited, but the DSP56F805's not only have two hardware ones built in, they also have timers that can be grouped to read quadrature. In one project I read 6 channels of quadrature inputs in hardware, and also read velocity of those inputs by timing the pulse widths with remaining timers.
Having the right processor for the job can make a huge difference.
--
Randy M. Dumse

Caution: Objects in mirror are more confused than they appear.
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
These chips would give me more resolution, which would make it worse. I'm using the external interrupt for 1 encoder and the change-on-port-b interrupt for the other one. When the interrupt fires I check the status of the other line to decide to increment or decrement the counter. At full speed I'm getting interrupts at something like 80khz. Since a 20mhz pic processes instructions at 5mhz, that gives me about 62 instructions between interupts. And with 2 channels of interupts at the same time it just swamps everything. I would drop in a 452 except the LVP is different and my compiler only supports teh 16 series, not the 18 series. I'm hoping to find some kind of circuit I can place in between the pic board and the encoder. Thanks Ringo
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Whoops. Just the second one (LS1766) would help you out. Maybe.
With these, you could let the encoders "free run" and poll them when you feel like it. It would limit the amount of interrupt driven overhead and give you better resolution. Seems win-win to me, but not sure of your total application. Dont' know if you have enough i/o to handle this or not. Don't remember the pinouts of pic16f877a and too lazy to go look for it at the moment.
JW
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

change-on-port-b
That's a bunch of ints/second! Why such a high resolution? Is the encoder on the motor shaft, but there is a reduction gear train following? If so, can you relocate the encoder wheel to a place where it turns slower? It doesn't seem likely that you really need that kind of resolution unless your robot is moving several hundred miles/hour. ;-)

The only other thing I can think of is to use a couple of flip flops to divide channel A by 4, 8 or 16 to slow down the int rate. You can still just look at the B channel just like always to determine the direction. It wouldn't be perfect in theory as it's susceptible to error when the wheel changes directions, but it may be good enough to get the job done in practice since you have such a high resolution to begin with.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
On Fri, 21 Oct 2005 08:47:45 -0700, ringo.davis wrote:

If you have the SPI port free (plus a free I/O bit) I have a dual 8 or 12 bit quadrature counter design that fits in a Xilinx XC9572XL (about $2.00)
It does require a free running clock at 2x the maximum quadrature count rate, and 3.3V for the XC9572XL
Its a delta-counter so the count is cleared when read, making it easier to create larger software counters by just adding the sign extended count to the (16, 24 or 32 bit) software counter.
Peter Wallace
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.