1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Broken quadrature encoder circuit on TI F281x DSPs?

Discussion in 'Embedded' started by Chris Carlen, Aug 25, 2005.

  1. Chris Carlen

    Chris Carlen Guest

    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.
     
    Chris Carlen, Aug 25, 2005
    #1
    1. Advertisements

  2. Chris Carlen

    Jerry Avins Guest

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

    Jerry
     
    Jerry Avins, Aug 25, 2005
    #2
    1. Advertisements

  3. Chris Carlen

    CBFalconer Guest

    Your waveforms would make more sense if you used a fixed width
    font.
     
    CBFalconer, Aug 25, 2005
    #3
  4. Chris Carlen

    Jerry Avins Guest

    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
     
    Jerry Avins, Aug 25, 2005
    #4
  5. 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
     
    Jim Granville, Aug 25, 2005
    #5
  6. 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
     
    Jim Granville, Aug 25, 2005
    #6
  7. Chris Carlen

    Jamie Guest

    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
     
    Jamie, Aug 25, 2005
    #7
  8. I read in sci.electronics.design that CBFalconer <>
    Isn't the font set by your e-mailer, not by the message?
     
    John Woodgate, Aug 25, 2005
    #8
  9. Chris Carlen

    CBFalconer Guest

    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.
     
    CBFalconer, Aug 25, 2005
    #9
  10. Chris Carlen

    jmeyer Guest

    .................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
     
    jmeyer, Aug 25, 2005
    #10
  11. 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.
     
    John Woodgate, Aug 25, 2005
    #11
  12. Chris Carlen

    Chris Carlen Guest


    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.
     
    Chris Carlen, Aug 25, 2005
    #12
  13. Chris Carlen

    Chris Carlen Guest

    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.
     
    Chris Carlen, Aug 25, 2005
    #13
  14. Chris Carlen

    Chris Carlen Guest


    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.
     
    Chris Carlen, Aug 25, 2005
    #14
  15. 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
     
    Jonathan Kirwan, Aug 25, 2005
    #15
  16. Chris Carlen

    Chris Carlen Guest


    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.
     
    Chris Carlen, Aug 25, 2005
    #16
  17. Chris Carlen

    Dave Hansen Guest

    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
     
    Dave Hansen, Aug 25, 2005
    #17
  18. Chris Carlen

    Jona Vark Guest

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


     
    Jona Vark, Aug 25, 2005
    #18
  19. Exactly correct. Now it looks right. You've identified the issue, I
    think.
    Neat. I like it much better, too.

    Jon
     
    Jonathan Kirwan, Aug 25, 2005
    #19
  20. Chris Carlen

    Ricardo Guest

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

    Ricardo
     
    Ricardo, Aug 25, 2005
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.