|
Hi, (Regarding the D-flip-flop implementation) I think Murphy invented encoders...... This is exactly the design I started with - and got burned bad! In my singleton "B" example, you will get extraneous pulse counts from this circuit. In this case, the encoder is riding on the "B" pulse rise transition. As I said earlier, this problem comes up when you are sitting still, and riding a transition edge so you may not have seen it if your encoder resolution is coarse and you are generally moving -- in your example, you may have not seen it if the drum was always moving one way or the other - or if you don't look at the encoder when it isn't moving.. Then again you may have seen it - once - but it never repeated so you ignored it. The problem is that it follows from the physical design of standard encoders that sooner or later they will produce one or all of these bizarre effects - unless the physical design of the thing being measured prevents the problem. (which may be the case for your drums -- or you may be..ahem.. "lucky" -- well captain, it worked for years..) The resolution of the encoder magnifies the odds of the problem because the transitions occur more frequently but the basic problem can/will occur on the coarsest of encoders under the right conditions -- you just have to stop at just the right spot..... I didn't really cover all the bizarre sequences you can get but they all revolve around the mechanical production of the pulses. There is no point in the sequence where you can't suddenly stop and jitter back and forth over a transition -- 3 out of 4 transitions are vulnerable - AND the sequence can backup at any point in the sequence -- adding more transitions, then reverse again, etc... Here are a few more nasty ones... Rotating past A rise, into the B pulse, then backing up, then forward, back, forward, etc.. (This riding the rising edge of B) A: __|-------------------...... B: ____|--|__|--|__|--|__.. Rotating past A rise, through B rise and jittering on the Falling edge of A.. (This riding the falling edge of A) A: __|---------|__|--|__|--|__|----...... B: ____|-------------------------- (This will also generate a zillion counts in the above circuit when moving in the opposite direction) In short - don't underestimate this as a problem when throwing in that encoder interface.. - just because it hasn't happened yet doesn't mean it can't. -Bill ----- Original Message ----- From: "linktek" <> To: <> Sent: Wednesday, June 04, 2003 4:33 PM Subject: Re: [68HC12] 9S12DG256 Quadrature Encoder Support. > Hi, > > You can implement a simple "no missing states" QD using a 74XX74 D-type > latch. Feed sya a into D and input B into CLK and also to a interrupt pin > on your micro. Feed Q into a input pin on your micro. Connect PRE and CLR > on the 74XX74 to Vcc. > > This way, with a interrupt you can pretty much examine the direction very > accuratly. Also pulse input will give you "length" count and pulse length > will give you "speed". > > I implemented this on a ships main trawl warps for large fishing ships.The > net is attached on both end with 2 drums of cable, these cables works > syncronously. Just imagine the cable going out over a 1km length and when > hauled back in, it reads different lengths............"oops captain, I can > explain.......have you ever heard of quadrature encoding, eh?" > > This implementation stood the test of time. With TIs little logic you can > buy a single tiny D-latch these days. All you still need is filtering. > > Gogetit > > Frank > ----- Original Message ----- > From: "John Dammeyer" <> > To: <> > Sent: Friday, June 04, 2004 11:47 AM > Subject: RE: [68HC12] 9S12DG256 Quadrature Encoder Support. > > Hi William, > > > > Well written! And even doing all this with a Micro and interrupts means > that the maximum jitter or > > encoder speed can't exceed the entire interrupt routine latency. > > > > John > > > > > > > > > -----Original Message----- > > > From: William M. Derby Jr. [mailto:] > > > Sent: Friday, June 04, 2004 11:30 AM > > > To: > > > Subject: Re: [68HC12] 9S12DG256 Quadrature Encoder Support. > > > > > > > > > The problem is that a valid "count" consists of a complete > > > sequence of A and > > > B pulses - you can't just take an arbitrary edge and be done > > > with it! There > > > are a bunch of pathological cases that real encoders produce > > > have that will > > > mess up the "simple" solution. (This would be the voice of > > > experience.) > > > > > > Consider an encoder sitting still -- well actually slightly > > > vibrating like > > > everything really does. You have a A and a B output which are > > > generally > > > produced by something blocking a light. Since the output is > > > mechanically > > > generated, you can easily have the start of a count pulse say > > > A -- then the > > > encoder direction reverses and A drops - -there is no B pulse at all! > > > > > > Valid Counts::: > > > A__---------______ > > > B____---------____ > > > > > > or in the other direction > > > > > > A____---------____ > > > B__---------______ > > > > > > Singleton, non- count events...... > > > > > > A____---------____ > > > B_______________ > > > > > > or in the other direction > > > > > > A_______________ > > > B____---------____ > > > > > > > > > Of course you can get a zillion of these if the encoder is > > > just sitting on > > > the edge of a transition.. > > > Depending on you implementation each one may show up as a > > > count! But wait > > > there's still more. > > > You can also get non-overlapped A-B pulses if the encoder > > > rotates little > > > further before backing up.. > > > This will lead to: > > > > > > A __|-------------|_____ > > > B_____------_________ > > > > > > or in the other direction... > > > > > > A_____------_________ > > > B __|-------------|_____ > > > > > > There are other cases as well -- In short, there is a reason > > > for the special > > > encoder chips (like the > > > LSI7183, which I use) and others mentioned which take care of > > > these bizarre > > > cases. Also remember that the pulse width will decrease with > > > the speed of > > > the encoder.. In extreme (high speed) cases, the pulse width > > > will dip below > > > the "allowable" pulse width (300ns on the 7183) and be > > > considered noise and > > > thrown out! If your encoder moves really fast in one > > > direction and slow in > > > the other, the position will appear to back up, each time the machine > > > cycles! > > > > > > Bill > > > > > > > > > ----- Original Message ----- > > > From: "Gary Olmstead" <> > > > To: <> > > > Sent: Friday, June 04, 2004 11:03 AM > > > Subject: RE: [68HC12] 9S12DG256 Quadrature Encoder Support. > > > > > > > > > > I'm not clear on what the big deal is. Two inputs, one > > > interrupt. At > > > > every (choose one) falling/rising edge, generate an interrupt which > > > > examines the level of the other input. One level > > > increments a counter, > > > the > > > > other level decrements the count. Shouldn't take long, > > > even at 20K Hz. > > > > > > > > And the problem is.....? > > > > > > > > Gary Olmstead > > > > Toucan Technology > > > > Ventura CA > > > > > > > > > > > > At 09:05 PM 5/31/04, you wrote: > > > > >John, > > > > > > > > > >I too have found this very annoying shortcoming on HC12 > > > counters. The > > > > >320F24x is far nicer ;-) > > > > > > > > > >The only solution I have thought of, but not tested is to use a > > > > >PIC12C508 or ATtiny12 (I have code for the PIC) to decode > > > the quadrature > > > > >into count and direction. The outputs of this device are > > > > >up-clock/down-clock. Then feed these clocks to the alternate pulse > > > > >accumulators (PA and PB) on a 9S12D device. The pulse accumulator > > > > >difference is the current count. The tricky bit seems to > > > be that you > > > > >would need to reset these counters before they overflow > > > (no big deal), > > > > >but making the read-reset operation indivisible to the > > > external clock > > > > >may lead to lost counts. > > > > > > > > > >My application can require 10KHz to 20KHz counting, so > > > interrupts put a > > > > >very heavy load on the processor. > > > > > > > > > >I will be curious to know how you solve the problem. > > > > > > > > > > > > > > > > > > > > > > > > --------------------To > > > learn more > > > about Motorola Microcontrollers, please visit > > > > http://www.motorola.com/mcu > > > > o learn more about Motorola Microcontrollers, please visit > > > > http://www.motorola.com/mcu > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor > > > --------------------~--> > > > Yahoo! Domains - Claim yours for only $14.70 > > > http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/dN_tlB/TM > > > -------------------------- > > > ------~-> > > > > > > --------------------To > > > learn more about Motorola Microcontrollers, please visit > > > http://www.motorola.com/mcu > > > o learn more about Motorola Microcontrollers, please visit > > > http://www.motorola.com/mcu > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------To learn more > about Motorola Microcontrollers, please visit > > http://www.motorola.com/mcu > > o learn more about Motorola Microcontrollers, please visit > > http://www.motorola.com/mcu > > > > Yahoo! Groups Links > > > > > > > > > > > > --------------------To learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > o learn more about Motorola Microcontrollers, please visit > http://www.motorola.com/mcu > > Yahoo! Groups Links > |