• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 81 subscribers
  • Views 2752 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

eQEP (Position counter initialisation and reset mode)

Mayank Jain70
Prodigy 210 points

Dear all

I am working on F28335 DSP board and struggling with understanding of few points in eQEP.

DOUBT 1 : What is the difference between position counter initialisation mode and position counter reset mode? (Let us take index event as reference for both).

MY UNDERSTANDING : On encountering index edge for first time the position counter will be loaded with QPOSINIT register value and for the subsequent index edges the position counter will be reset to (0 or QPOSMAX)?  

(Please tell what I  understood is correct, if not please specify the correct interpretation).

 

DOUBT 2: If software initialisation is used, then in that case, since the bit is not automatically cleared, the position counter will always be reinitialised and not reset at any event. { But at what event? is it the index again or any other event?}  In an example for FOC of PMSM given by MATLAB Simulink, the eQEP was initialised by software and not index event. If you have any idea, then please do tell about it too. 

(Software initialisation is not at all clear)

 

NOTE: I have gone through the reference guide SPRUG05A before posting this query.

 

Regards

Mayank Jain

  • 0
    TI__Guru 57255 points

    Hi Mayank,

    When using the index to reset the QEP timer, the functionality that comes out of IEI (which utilizes QPOSINIT) and PCRM are similar.  However, there are nuanced differences (and they could theoretically work against each other).  I can understand how your confusion can arise.

    IEI = 2 or 3, will initialize (or set) the QPOSCNT counter on every index event, not just the first instance.


    Below are four use-cases which I've seen:

    1. PCRM = 1, IEI = 0 or 1
    2. PCRM = 1, IEI = 2 or 3
    3. PCRM = 0 or 2
    4. PCRM = 3, IEI = 0 or 1

    [1] is a relatively straightforward implementation where the index has no effect.  The position counter gets reset when the counter overflows/underflows
    [2] is similar to [1], but the index will help correct for any errors in A or B that have accumulated over time.  Works well if index is defined as A && B or similar (ie the index is 1/4 of a QEP period)
    [3] is similar to [2], but extra logic exists to try and account for indexes > 1/4 cycle wide
    [4] is a no index case where speed measurement is a major goal.

    At any time, you could force the QPOSCNT to some QPOSINIT via software (SWI) if desired.  According to the documentation, the bit is not cleared but the effect only happens at the moment you force the SWI.  Others on my team have used SWI, but I have not personally.

    Hopefully this makes some sense and helps.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Prodigy 210 points
    HI Bret
    Thank you so much for replying

    CASE 1: Obvious because IEI bits are disabled and so counter's behavior will be determined by PCRM Only. (Perfectly clear to me).

    Let me take some entries as a reference so that final response could be in terms of figures for a clear explanation....
    QPOSMAX: 65335; QPOSINIT : 256 ; (Let Encoder be of 1000 lines and so index will be of 4000 counts.) Assume forward direction (Quadrature count mode)

    CASE 2 : How will index be correcting the error? With PCRM=1, IEI=2;
    Predicting response with my understanding:
    Now position counter (QPOSCNT) will start counting from zero till 4000, and then it gets reset to 256 value because of IEI, then further after (256+ 4000 counts), it gets reset to 256 again. This goes on and on. Thus the PCRM mode actually does not work here as position counter will never be able to reach maximum value. (Now please correct me in terms of the above values).

    CASE 3: With PCRM=0 or 2, the IEI bits are ignored and so, with them behavior of position counter will only be determined by PCRM.
    RESULT : Position counter starts from zero, reaches 4000 and get reset to zero, then starts again and reaches {4000 (for PCRM=0) or 65335 (PCRM=2)} after which it gets reset to 0 again... this goes on...

    CASE 4: PCRM=3, IEI bits are disabled. (This is entirely different. No problem with this.)

    As far as software initialization is concerned, we can force SWI=1 at any point of counter reading and force QPOSINIT to QPOSCNT. eq. when at an instant QPOSCNT=398, if we force SWI=1, then QPOSCNT=256, and starts incrementing from there. Now it reaches somewhere around 4789, if SWI=1 is forced again, then QPOSCNT = 256 again.

    Regards
    Mayank Jain
  • 0 in reply to Mayank Jain70
    TI__Guru 57255 points

    Hi Mayank,

    CASE 2: With the entries you've chosen, the index will be used directly to set the counter to 256 and, as you've mentioned, the PCRM logic won't do anything. 

    If any A or B glitches occur over time, the index (via IEI) will correct for it - and this is what I meant by correcting the error. 

    If you plan to set QPOSINIT to anything non-0, I would highly recommend having QPOSMAX be 3999 such that PCRM will wrap QPOSCNT around (and QPOSCNT will therefore always be 0 to 3999).  Otherwise, the direction of the encoder may mess the number-line up.  The number-line being completely consistent and continuous across all conditions is critical.

    Even if QPOSINIT is 0, it's often best if QPOSMAX is configured to match the line count of your encoder.

    ===

    CASE 3: Similar to CASE 2 when QPOSMAX is configured to 3999.

    ===

    CASE 3B: An alternate situation to CASE 3 is where QPOSMAX is 3999, QPOSINIT is 0, PCRM = 2, IEI = 0, IEL = 1 (and the encoder's index pulse is defined as 1/4 of a encoder pulse QEP period).  In this case the index will only once do something to force QPOSCNT.  Afterward, QPOSCNT's value will be latched into QPOSILAT when the index event occurs.  Software can then determine if a fault occurred by looking at QPOSILAT and then corrective action could be taken.  The number line is held consistant solely by PCRM after the first index event.


    Thank you,
    Brett


    edit (12Aug2016): encoder pulse -> QEP

  • 0 in reply to Brett Larimore
    Prodigy 210 points
    Hi Brett

    Thank you so much for a clear explanation...

    Just new things I have in my mind now, for case 3B: I am not clear with
    "the encoder's index pulse is defined as 1/4 of a encoder pulse period. In this case the index will only once do something to force QPOSCNT"

    1. (the encoder's index pulse is defined as 1/4 of a encoder pulse period) : 4 QCLK per index period

    2. the index will only once do something to force QPOSCNT
    With IEL=1, Just at the start, first on encountering an index pulse rising edge, it would then look for the quadrature edge( of A & B anyone that comes first) and on that edge (of A or B) it would latch the QPOSCNT ( which is going to be 3999) to QPOSILAT.
    It would then remember the edge of (A or B) and use the same edge configuration for latching.
    Since QPOSMAX is set to 3999, then the index latching and the maximum position will tend to coincide each other and so both would give same reading to QPOSILAT. (IS THAT WHAT YOU WANT TO SAY).

    Thank You
    Mayank
  • 0 in reply to Mayank Jain70
    TI__Guru 57255 points

    Hi Mayank,

    [1]

    I've edited my earlier response to match what I was trying to say.  Perhaps saying that the index pulse contains 1 QCLK is a cleaner way of stating things.  

    In my  response here, I am stating the condition of 1 QCLK per 1 index pulse.  It is possible that to use the internal smarts of the QEP, from PCRM = 0 and PCRM=2 for larger index sizes.  However, some thought needs to be put in to make sure that the number-wheel is continuous in these cases.  For simplicity of conversation, I'm sticking with the simpler case.  (the description of what we're talking about is complicated enough without adding more! ;) )

    Please also be mindful that there is an errata titled "Position Counter Incorrectly Reset on Direction Change During Index" which can affect PCRM = 0 mode.  The errata, as described there, may or may not be important depending on the exact application.

    ===

    [2] Yes, that is the idea.


    Thank you,
    Brett