On Wed, 19 Mar 2014 11:35:36 -0500, Tim Wescott wrote:> On Wed, 19 Mar 2014 11:39:50 +0000, alb wrote: > >> Hi Tim, >> Tim Wescott <tim@seemywebsite.please> wrote: >> [] >>>> I think I was confused as well. The signals have a constant phase >>>> between them and their frequency is proportional to the speed of the >>>> mechanism that we need to drive. I completely misunderstood the >>>> problem I posted! >>>> Ouch. >>> >>> Is this just a garden-variety incremental quadrature encoder, or >>> perhaps an encoder with a sinusoid (rather than square wave) output? >> >> Pierre Bonnard once said: The precision of naming takes away from the >> uniqueness of seeing. >> >> >>> In that case then there are some excellent well-established techniques >>> for dealing with the signals. >> >> And now that I know what to look/ask for, loads of hits are popping up. >> At least now I have a place where to start! >> >>>> The signals have a fixed phase among them and a variable frequency >>>> which depends on the speed of the mechanism. The mechanism scan in >>>> one direction first, breaks, stops and accelerates to go in the >>>> reverse direction...therefore the frequency goes from a nominal value >>>> when the speed is constant to zero and then back again to the nominal >>>> value. >>> >>> Normally I try not to pick spell-checker nits, but this one tickled my >>> funny bone. Forgive me. You mean "brakes". If you read "break" >>> literally, then you need a "repairs itself" right before or right >>> after "stops". >> >> I must admit that was funny! My fingers are too used to 'break' >> instructions ;-). I usually read before posting but that mistake made >> it through (see http://danalookadoo.com/psychology/jumbled-text/). >> >>>> Thanks for asking, it made me ask and now the problem is much more >>>> clear than what it was. We lock on the frequency. Sorry for the >>>> confusion :-/ >>> >>> If it's an encoder then you don't need to lock onto the frequency at >>> all -- you can maintain a differential position reading that's as >>> accurate as the encoder output. If the encoder has an index pulse or >>> other way to get the absolute position reading in one spot, the >>> encoder + index will be an absolute, and not a differential, position. >> >> We have what we call a top-zero sensor which is providing the absolute >> position. >> >> Thanks a lot for the hints. I'll post back after some reading, it will >> certainly be more effective. > > If you do, indeed, have a quadrature incremental encoder, then you'll > find a lot of different ways of decoding it. Each one has the quality > that the person presenting it thinks it's just great, but only a few > have the qualities of being compact and robust. > > Avoid the ones that say "use channel A as a direction and channel B as a > clock", or some variation -- those all suffer from the problem that > jitter on one line (the "clock" line) will translate to erroneous > motion. They work well if the mechanism is always moving in one > direction, but generate some pretty severe and head-scratching errors if > the mechanism spends a lot of time stopped or creeping slowly. > > The thing to remember about these encoders is that each transition of > either line denotes a motion in one direction or another, and as long as > you capture no more than one transition, the prior state of the encoder > plus the current state of the encoder uniquely determines whether a > transition has happened and it's direction. > > The way that I do these in software is to sample fast enough that I'm > guaranteed to capture every real transition (jitter doesn't cause severe > problems with this method). I take the captured encoder state and turn > it into straight binary (00, 01, 10, 11), I compare it to the bottom two > bits of a "position" register, and I increment or decrement the register > as necessary to reconcile things. > > I suspect that in an FPGA it'd be far more compact to just concatenate > the "prior" and "current" readings into a four-bit word and extract the > actions (increment, decrement, do nothing, or pop a fault). This would > use one or to LUTs, as opposed to the adders and whatnot that the > software version uses (but which come for free in a microprocessor).The C code goes something like this. Take PORT as a two-bit read of the encoder, and all variables as integers: current = PORT; current = (current & 0x03) ^ ((current & 0x01) << 1); // turn to binary increment = (current - position) & 0x03; fail_if(increment == 2); // or error handling of your choice. if (increment = 1) ++position; if (increment = 3) --position; Note: - position can be as wide as you want. - the bottom two bits of position are locked to the encoder. - an increment of 2 means a part failure, or you're not sampling fast enough. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
costas loop
Started by ●March 17, 2014
Reply by ●March 19, 20142014-03-19
