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.

PMSM FOC using eQEP with Quadrature Incremental Rotary Encoder

Other Parts Discussed in Thread: TMS320F2802, CONTROLSUITE

Hi Chris,

I wasn't exactly sure where to post this question so I figured I would post it here.  Please feel free to move it to the appropriate thread if necessary. 

Subject: PMSM FOC using eQEP with Quadrature Incremental Rotary Encoder on TMS320F2802.

Concern:  We want to use a quadrature incremental rotary encoder for FOC control of a permanent magnet synchronous motor (PMSM). However, this motor can run continuously and we are concerned about the FOC angle being off over time (months to years) due to loss or gain of a pulse and this error accumulating over time.  Would using the Index pulse eliminate this error?  Or do we then need to worry about not receiving an Index pulse.  I was concerned about this advisory from Texas Instruments, “If the first index event at the QEPI input occurs at any time from one system clock cycle before the corresponding QEPA/B edge to two system clock cycles after the corresponding QEPA/B edge, then the eQEP module may miss this index event.”  Do you have any industry experience with this?  Can you provide some insight into this?  Would we have to worry about field failures over time due to this possible issue?

Question:  Is an index pulse from the encoder needed for FOC control of a PMSM motor?  Without the index pulse would we have to worry about the accumulative error over time due to any possible loss or gain of encoder edges?  Can you provide any details on solutions?

Thank you in advance for your help with this.  I look forward to hearing back from you.

 

Best regards,

Bill Szatkiewicz

(954) 729-5541

 

  • Bill,

    As with all good answers, it depends.  Will you be running any sensorless algorithm in your controller?

    If not (and you're doing FOC), you are essentially relying on the incremental encoder to give you your motor's speed and angle information.  Getting the speed will be no issue - the A & B outputs will give you this easily.  Getting the angle information is the problem.

    In a system without a sensorless algorithm and without an index pulse, you can likely lock the rotor (set Q as 0 and D as some number) and then know figure out where 0degrees electrical is.  You'd then set this position as the 0 point on the QEP peripheral and rely on the encoder to give you the correct angle as you're spinning the motor.  It is possible that you'll miss a pulse, but missing a few probably won't be too major of an issue: your control algorithm will still work and efficiency will most likely still be pretty good.  It'd be the aggregation of errors over time that'd be concerning.  I don't have much experience with how often encoder pulse misses occur and with what level of noise, so I unfortunately cannot speak to that.

    The index pulse resolves a lot of these issues.  With it, any A/B pulses missed will be resolved after one revolution of the motor.  If you were to miss one index pulse, the next index pulse will most likely be quick enough to resolve your A/B errors.  If you keep missing index events, you probably have major signal integrity issues (like loose cables) which are also affecting A&B.

    Please note that there also provisions to throw an interrupt if the QEP module senses that the index pulse wasn't received when you think it should have which means you can track these errors over time.  There a few other features like this which could be utilized in software to make the system more stable, warn of issues, etc.

    The errata advisory with regard to the index pulse only relates to the first instance of an index pulse.  This just means that your first 'search for home/zero' may take up to 2 revolutions.

    If you're doing speed control not having the index pulse may be 'good enough' or may not - this depends on your application.  It is not ideal though. For servo systems, this won't be good enough (using incremental encoders on their own may not be adequate either though).

    Hopefully this helps.


    Thank you,
    Brett

  • Hi Brett,

    Thanks for the reply.  Your response is greatly appreciated!  I figured the response might be along the lines of "depends upon the application and environment", which is expected. 

    To give you some background.  I originally developed a sensorless control using the sliding mode observer for the angle and speed feedback.  However, the low speed performance was not acceptable for the application.  This lead us to put an encoder on the motor and do FOC with the encoder driving both the ange and speed feedback, eliminating the sliding mode observer completely.  However, this was done with only one edge of the quadratue encoder going into the eCAP module to confirm feasibility.  So, we did have start up and direction issues. We are now in the process of developing the required hardware for full quadratute encoder feedback with the eQEP.

    As you mentioned using the encoder for speed is not the issue, its the fact that the encoder is solely responsible for the angle to the FOC.  So, to answer your question, right now we are not using any sensoless algorith in the controller.  Would there be a combination of sensorless algorithm plus encoder feedback, which you think would be more beneficial and still give us good low speed performance? If so, can you provide any literature regarding this?

    I think we will ultimately use the index pulse to eliminate any loss or gain of QEPA/B edges.  You made a good point that even if the controller misses an index pulse, the next index pulse should happen soon enough to correct for any errors over one or two mechanical revolutions without causing to much degragation in efficiency.

    Do you have any technical application notes which show the setup and code sippet for the eQEP module in the TMS320F2802 for FOC control of PMSM motor with encoder feedback? 

    When performing the zeroing of the electrical angle.  I have read some articles stating to apply dc reference with Id=0 and Iq=align torque, however, I also have read some that state to apply id=align torque and Iq=0.  Can you please confirm which is correct?  My assumption is that once the alignment has been performed and the motor is locked to that position, you then rotate the electrical angle by 90 degrees and then continue commutation based on the encoder edges coming in.  Can you please confirm this?  I am looking to clear up some confusion I have with this. How do I know I am properly aligned?

    We are just doing speed control so do you think using the encoder feedback with index pulse for angle and speed will be reliable?

    I hope my questions are understandable.  Thanks again for all your help with this.

    Regards,

    Bill S.

  • Hi Bill,

    Bill Szatkiewicz said:

    As you mentioned using the encoder for speed is not the issue, its the fact that the encoder is solely responsible for the angle to the FOC.  So, to answer your question, right now we are not using any sensoless algorith in the controller.  Would there be a combination of sensorless algorithm plus encoder feedback, which you think would be more beneficial and still give us good low speed performance? If so, can you provide any literature regarding this?



    [Brett] No. I don't have any literature available to describe this, but it can be a powerful approach.  The main idea is that you rely on the encoder, but use the sensorless algorithm as a way of checking that the encoder's data is logical.  You should expect some fudge factor at low speed (depending on the quality of your observer, layout, etc). 


    Bill Szatkiewicz said:

    Do you have any technical application notes which show the setup and code sippet for the eQEP module in the TMS320F2802 for FOC control of PMSM motor with encoder feedback? 



    [Brett] The closest thing I can recommend is some of the software examples from controlSUITE.  We don't have any software specifically for the F2802, but the F28335 is similar - the main difference is speed and the addition of floating point. The F2803x is a bit more different - the main difference speed, the ADC, but there are more.

    TMDSHVMTRPFCKIT software:
    \controlSUITE\development_kits\HVMotorCtrl+PfcKit_v2.1\

    The following appnote can help you compare C2000 MCU differences:
    http://www.ti.com/lit/spru566


    Bill Szatkiewicz said:

    When performing the zeroing of the electrical angle.  I have read some articles stating to apply dc reference with Id=0 and Iq=align torque, however, I also have read some that state to apply id=align torque and Iq=0.  Can you please confirm which is correct?  My assumption is that once the alignment has been performed and the motor is locked to that position, you then rotate the electrical angle by 90 degrees and then continue commutation based on the encoder edges coming in.  Can you please confirm this?  I am looking to clear up some confusion I have with this. How do I know I am properly aligned?



    [Brett] For alignment you'd want to generate 0 torque (Q), but generate just enough flux (D) to allow your electromagnet to align with the permanent magnets (without demagnetizing it!). 

    (I realize now that I made a mistake in my previous post.  Aligning by setting Ds and Qs uses the FOC methodolgy. And the FOC didn't know the angle yet which was the root issue.  It's probably more reasonable to carefully set specific PWM duty cycles for U, V & W such that you create a magnetic field which corresponds to 0 position.)


    Bill Szatkiewicz said:

    We are just doing speed control so do you think using the encoder feedback with index pulse for angle and speed will be reliable?



    [Brett] Yes.  We have customers that use this methodology.


    Thank you,
    Brett

  • Hi Brett,

    Thanks again for all your help and for the information you provided.  I appreciate it.  I think you cleared up everything for now.  If anything else comes up I will let you. 

    Cheers,

    Bill S.

  • Hi Brett,

    Subject:  Initial Alignment of FOC of PMSM with Quadrature Encoder on TMS320F2802.

    After a sysem reset, the rotor flux position is in an unknown position.  A fixed stator current vector is applied to the motor until it aligns itself.  The rotor flux is now in a known position but this position is not yet aligned with the D axis. 90 electrical degrees is added to the value of the stator current vector.  This action is equivalent to a frame rotation and instantaneously, the stator current vector is moved 90 degrees apart from its first position. The D axis now corresponds exactly to the rotor flux.  As there is this 90 degree angular difference between the rotor flux and the stator flux, the interaction of the two fluxes produces torque and the rotor starts to rotate in order to align itself. 

    I have successfully implemented the above condition. However, upon doing the above for the first time after power up the rotor does not always move in the same direction after the alignment process.  That is when shifting by 90 degrees for the first time, the rotor does not always go in the same direction.  Sometimes it goes in the opposite direction.  Is this just the nature of this process or am I missing something? 

    Please let me know if you have any other questions.  I look forward to hearing back from you.

    Thanks,

    Bill S.

     

  • Bill,

    If you haven't already, might I recommend for you to take a look at the document reference below (which is located in controlSUITE) and compare it to your methodology - of most interest will be the figure on pg35:
    \controlSUITE\development_kits\HVMotorCtrl+PfcKit_v2.1\HVPM_Sensored\~Docs\

    The variable lsw is what changes the state of the control: 0 = locked rotor, 1 = closed torque loop, 2 = closed torque and speed loop. 

    In your system (and after the alignment step), does it keep going in the 'wrong' direction or does it start going one direction and then 'fix' itself?


    Thank you,
    Brett

  • Brett,

    Thank you for your response.  That diagram certainly helps.  I have seen it before. I figured out my issue.  I was artificially forcing Iq to always be positive.  Even in the reverse direction.  This software trick I used for sensorless applications was causing the issue. Once, I removed that and allowed +iq to ask for motoring in one direction and -iq to ask for motoring current in the opposite direction the problem was solved.  Thanks again for all your support. It's much appreciated.

    Cheers,

    Bill S.

  • The reason I did that in the sensorless application was because my speed feedback was absolute.  Having the qudrature encoder which provides directional feedback as well as speed feedback certainly helps. Thanks again.

  • Hi Brett,

    Hope you had a nice Thanksgiving.  I have a problem with my FOC of PMSM with Quadrature Encoder.  The problem only occurs less than 1% of the time on a system power up.  For example, I only see the problem 1 time out of over 500 power-up cycles. The problem is that the motor goes full speed in the wrong direction.  I checked the polarity of the qep.QDF bit and it is correct when the problem occurs.  The reason I checked that is because the wrong polarity on my speed feedback could explain what is happening but after testing the polarity was not the cause. The problem has also only been observed when the motor is coincidentally at the electrical angle I am trying to align to and therefore no encoder edges are received before the closed loop system is enabled.  Also note that I have observed the problem NOT happen under those same conditions, so it is somewhat random.  However, I have never seen the problem happen when the motor does have to move during the alignment phase and encoder edges are received before enabling the closed loop system.  Do you know of this issue or have you seen it before?  Do you have any recommendations of things for me to try?  Could it have anything to do with power-up glitches, the /XRS pin, or pin qualification of the eQEP pins?  We do hold the /XRS pin low for some time on power-up, until our bus voltage gets to an adequate level.  Any help would be greatly appreciated.

    I have been trying to figure out the cause of this issue for days. In the interim I have implemented software to force the motor to move during the alignment phase to test if the problem never occurs with that logic. Looking forward to hearing back from you.  If you have any questions or need help better understanding my question please let me know and I will do my best to clear things up.  Thanks in advance.

    Regards,

    Bill S.

  • Brett,

    After some testing when forcing the motor to move during the alignment phase the problem never occurs.  I have tested over 2500 power up cycles with no errors. Please let me know if you have any thoughts regarding this.

    Thanks,

    Bill S.

  • Hi Bill,

    Sorry for the delay in response. Are you still having trouble here?

    After the flux alignment stage, what is the value in the QEP counter? If it is non-zero, you should probably set it to zero. My thought is that the QEP is missing the index pulse and therefore the counter may be at some unknown value.

    Forcing movement for a short time (in a known direction) until closing the loop is, I believe, also somewhat common.


    Thank you,
    Brett
  • Hi Brett,

    As I mentioned above as long as I force the motor to move during the alignment stage the problem goes away. However, I still do not know what caued the issue. After the flux alignment stage, I do zero the QEP counter (EQep1Regs.QPOSCNT = 0;) so it alway applies the correct 90 degree shift after the alignment stage. 0 electrical degrees after alignment because during the alignment phase I align to -90 electrical degrees. Thanks for the reply. Let me know if that sparks any other thoughts.

    Thanks,
    Bill S.