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

NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.

 

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

Jerry

 

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

 

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

 

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

 

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

 

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.
http://webpages.charter.net/jamie_5

 

I read in sci.electronics.design that CBFalconer <>

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

 

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.

 

.................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

 

I read in sci.electronics.design that CBFalconer <>

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.

 

Interesting combination huh, "timing diagrams and diatribes."

:-D


--
_______________________________________________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA

NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.

 

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

NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.

 

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

NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.

 

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

 

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

NOTE, delete texts: "RemoveThis" and "BOGUS" from email address to reply.

 

On Thu, 25 Aug 2005 10:17:05 -0700, 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

 

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

 

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

Neat. I like it much better, too.

Jon

 

Dave Hansen escreveu:This looks right here.
<snip>
This doesn't(it's one char too few in the upper line).

Ricardo