Broken quadrature encoder circuit on TI F281x DSPs?

Hi:

I have BEI encoders which make waveforms which look like:

N-1 N 0 1 2 3 4 5 ... ______ ______ ______ ______ B: ______ ______ ______ ______ ___ ______ ______ ______ ___ A: ______ ______ ______ ______ ______ Z: __________________ ________________________

Now the thing is, that because the signals are generated by an opto-mechanical interruptor, one cannot be certain that the edges which appear to line up between the Z pulse and the B pulse train, really are occurring before or after each other.

So a proper logic design to decode the signals into a count that is accurate on a 1/4-cycle basis and can recalibrate itself to an absolute zero position using the Z pulse when running either forward or backward would involve a state machine that resets to zero at some defined condition such as having both A and B high when the Z is high. Then it won't matter if the direction is forward or backward, the count will always become zero within the correct 1/4 cycle, and it also won't matter if the edges of B vs. Z lead or lag each other slightly.

Well I would have thought this is how things would work with the F2812 QEP circuit, because that's what it says it can do. But it doesn't work. It only resets the count to zero (when the EXTCONx.QEPIQUAL bit is set) when the Z pulse happens clearly *within* the 1/4 cycle in which A and B are both high. Ie, the rising edge of Z must occur after A = B = 1. It is edge sensitive to Z rather than condition sensitive of A=B=Z.

That means, the only way Z resets is if my pulses look like this:

____ _____ ____ ____ A: ____ ____ ____ ____ __ ____ _____ ____ __ B: ____ ____ ____ ____ _ Z: _______________ ________________

But as far as I know (only having experience with BEI encoders) is that most encoders produce Z pulses that are a full half-cycle wide, and look like my first diagram above (with the mentioned edge timing uncertainty).

Thus, the TI QEP circuit is bungled because if I did somehow have an encoder that produced pulses like this, I would get an extra count in the forward direction:

Let's say I have a 12 position encoder. My counts should be in the set {0, 1, 2,..., 11}. But I'd get a brief forward count of 12 with this situation, but reverse would be OK (after an initial forward pass):

FWD: 5 6 7 8 9 10 11 12 0 1 2 3 4 REV: 5 6 7 8 9 10 11 0 1 2 3 4 ________ ___________ ________ B: ________ __________ ________ ____ _________ __________ ____ A: ________ __________ ________ __ Z: __________________________________ _________________

I'd say this is not good!

There is another mode if the EXTCONx.QEPIQUAL bit is not set in which the counter resets to zero whenever there's a rising Z edge, regardless of the state of the phases. In this case, I'd get a 1/4 cycle error between the two directions (with a real BEI encoder waveform):

FWD: 6 7 8 9 10 11 0 1 2 3 4 5 REV: 5 6 7 8 9 10 11 0 1 2 3 4 ________ ___________ ________ B: ________ __________ ________ ____ _________ __________ ____ A: ________ __________ ________ ___________ Z: __________________________ _________________

Oh, but actually things could be much worse because if the Z edges lag B, then I get extra glitch counts again!

Ugh!

How could TI do it this way?

Has anybody found this to actually work correctly?

I'll be sending them an inquiry about this tomorrow.

Good night!

--
_______________________________________________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
Reply to
Chris Carlen
Loading thread data ...

Read over United States Patent 4300039, then we'll correspond further.

Jerry

--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

Your waveforms would make more sense if you used a fixed width font.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
Reply to
CBFalconer

It's not quite so simple. Consider what happens when the encoder oscillates back and forth across a B transition without A changing at all. The old solution is a state machine. The new solution (mine) with hardware uses two XOR gates and yields double or quadruple the basic resolution of the wheel.

Jerry

--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply to
Jerry Avins

But you are about to reset, so all you are talking about is a one count skew in the MAX possible number, just before reset.

At least they gave a RESET, and gave you a choice on the mode :)

Sounds like they tried to "cover the bases", and the first option is preferrable, if the encoder allows; if it has a wide Z, then you need

2nd option, but as you say, that can have Zero exit errors, but as long as the edges swallowed inside Z are stable, you should get stable counts on either side, again with a small +/- 1 error on 'absolute' location. Normally, you use much finer quad steps, than your system needs, so this level of detail should not be a practical issue. [ Level sense on Z would probably have been better design, but maybe they wanted to avoid wide/unknown dead-bands ? ]

-jg

Reply to
Jim Granville

Not sure I'd call Nov 10 1981 'new' ? XOR based quad solutions have been around a very long time : You need either a pulse generator ( hard in an ASIC, or FPGA) or some FF's, and a faster clock, to do effectively the same thing. In today's digital fabric, the FF's are cheaper, and simulate correctly, and avoid issues with clock domain crossing... to .

-jg

Reply to
Jim Granville

the above looks correct to me. depending on how you want to do it. (B) input is good for counting on the raising edge because (Z) follows it. (A) can be used to determine the direction you are going when (B) raises.

looks simple to me.

Real Programmers Do things like this.

formatting link

Reply to
Jamie

I read in sci.electronics.design that CBFalconer wrote (in ) about 'Broken quadrature encoder circuit on TI F281x DSPs?', on Thu, 25 Aug 2005:

Isn't the font set by your e-mailer, not by the message?

--
Regards, John Woodgate, OOO - Own Opinions Only.
If everything has been designed, a god designed evolution by natural selection.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk
Reply to
John Woodgate

Yes, but the result then doesn't match what you saw when you wrote it. The vast majority of e-mail and netnews are displayed in fixed font. The result is that waveform edges are displaced from what you drew. Even if the receiver used a variable width font, there is absolutely no guarantee that his spacing matches yours. With a fixed width font there is such a guarantee.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
Reply to
CBFalconer

On Wed, 24 Aug 2005 22:11:22 -0400, Jerry Avins wroth:

................bunch of stuff clipped...............

Dear Jerry, It is seldom necessary to quote an entire message filled with timing diagrams and diatribes simply to add a one line reply.

Jim

Reply to
jmeyer

The diagram seemed to make sense to me when displayed in Courier New. So I have no reason to assume that the OP used a proportional font. YMMV, I suppose.

--
Regards, John Woodgate, OOO - Own Opinions Only.
If everything has been designed, a god designed evolution by natural selection.
http://www.jmwa.demon.co.uk Also see http://www.isce.org.uk
Reply to
John Woodgate

Interesting combination huh, "timing diagrams and diatribes."

:-D

-- _______________________________________________________________________ Christopher R. Carlen Principal Laser/Optical Technologist Sandia National Laboratories CA USA snipped-for-privacy@BOGUSsandia.gov NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.

Reply to
Chris Carlen

Yes. But actually it is Ok, because there is a period register for the timer that will ensure it can't ever count beyond the encoder resolution. Thus, the if the Z pulse lags and the first revolution starts with an under-count, then the Z pulse will reset things the first time and be ignored thereafter.

The only deficiency is that it cannot reset in the reverse direction. Since our application is mainly one-directional, this isn't a serious problem. Nor it's more of a disappointment. There are times when we will want to manually move our shaft forward and backward over the zero point for alignment purposes, so it is actually essential that we can maintain accurate 1/4 cycle counting throughout. It seems that is possible, as long as one forward pass is first made through Z.

Also, I will have to guarantee that Z rising edge occurs after the two phases are high. That is what really bugs me. The correct implementation would be a condition sensitive reset, when A=B=Z=1. But they have Z edge sensitive instead, which also contradicts what they say in the documentation.

Yeah, perhaps. Are there wide variations in the implementation of index signals on encoders throughout the industry? Unfortunately, I only have worked with BEI. Oh actually, we had an older brand that we've since replaced which also worked just like BEI. Z pulse was fairly in line with a single pulse of one phase.

Good day!

--
_______________________________________________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
Reply to
Chris Carlen

Thanks for the input Jerry.

I am aware of such methods. I wish to avoid building my own quadrature decode hardware. I could do it if I want, and would probably do it with a state machine in a FPGA that I plan to have nearby the DSP for misc. logic tasks.

But the reason I want to rely on the F281x QEP circuitry is that I will be using the compare match function as well. Also period interrupts. Of course, all this can be done as well with the PLD, but if I can make the DSP's circuitry work, then that's the most straightforward path.

It turns out that while I think they did blow it in terms of the most sensible implementation, I can get working results with just a minor external hardware trick.

If I simply can guarantee that the Z rising edge occurs after the condition A=B=1 is satisfied, as well as setting the counter period to the encoder's max count, then actually I can't ever get an extra count. The only deficiency is that it can only sync to absolute position in one direction. But that is fortunately not a bog problem in this application.

Good day!

--
_______________________________________________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
Reply to
Chris Carlen

I'm using Lucida Console 10, also a fixed spaced font, and it doesn't look good, at all. So I switched over to Courier New to re-examine the output. No better. I think it must have originally been drawn in a variable pitch font.

Jon

Reply to
Jonathan Kirwan

Nope. Very fixed width here in my Mozilla Mail composer using text mode. Interestingly, my mail config has a place to select whether to compose in HTML, I have that unchecked. Then there is a place to select which font to use for HTML message compositions. That was set to variable. However, I am not composing in HTML so it should not apply. furthermore, the mail I am composing now, just as the one with the timings, was very clearly fixed width, as evidenced by the fact that the characters of all lines form straight vertical columns on nmy screen.

So things like this look right:

N-1 N 0 1 2 3 4 5 ... ______ ______ ______ ______ B: ______ ______ ______ ______ ___ ______ ______ ______ ___ A: ______ ______ ______ ______ ______ Z: __________________ ________________________

The edges of B and Z waveforms line up vertically, and the numbers above are centered within 1/4 cycles of the waveform.

But thanks for trying to look at my post.

Good day!

--
_______________________________________________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarleRemoveThis@BOGUSsandia.gov
NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.
Reply to
Chris Carlen
[...]

Almost, but not quite lined up when it got here. It looks like either the upper lines gained a space, or the lower ones lost one. If I make a minor correction, I get:

Which at least appears correct on my system. FWIW, if I were drawing it, I'd put in the vertical markers, and try to line the numbers up on them, e.g.

This would have made it easier for me to follow, anyway...

Regards,

-=Dave

--
Change is inevitable, progress is not.
Reply to
Dave Hansen

How petty.. it si a QUADRATURE encoder. The waveforms are all the same.. If you've seen one.

Reply to
Jona Vark

Exactly correct. Now it looks right. You've identified the issue, I think.

Neat. I like it much better, too.

Jon

Reply to
Jonathan Kirwan

Dave Hansen escreveu:

This looks right here.

This doesn't(it's one char too few in the upper line).

Ricardo

Reply to
Ricardo

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.