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.

Motor Identification understanding for FOC.

Hello TI,
I have following questions regarding motor identification on instaspin FOC:
1.) With a known motor can i fill in the motor parameters directly in user.h. I have executed the Labs multiple times and i see the results vary over a large range. I want to resolve this with using values provided by motor manufacturer.
2.) Once the motor parameters are identified (by some means) are only the Kp and Ki parameters that needs tuning.
3.) Are the parameters identified consistent for the motor over the Motor specified Speed range. I wanted to understand if the Motor identification part needs to be redone if i want to run the motor conistently at whole range of minumum to maximum motor rated speed.
4.) For FOC how to determine the lowest operating speed that can be supported by TI solution + Motor. What HW parameters matter and to what proportion.
5.) At manufacturing stage what is the suggested course for Motor identification parameters.
Best regards
Aj

  • AJ,

    Aj Thomas said:
    1.) With a known motor can i fill in the motor parameters directly in user.h. I have executed the Labs multiple times and i see the results vary over a large range. I want to resolve this with using values provided by motor manufacturer.

    In general yes, if you believe the values you are using. Most Motor Datasheets are close, but they all have some error.  Some notes on the 3 variables for synchronous motors.

    Rs: It is recommended to run an RsRecalc before starting the motor, especially if you are going to run at / through lower speeds where Rs value is more dominant.  If you are running at high loads and/or low speeds you will likely need to use the RsOnline feature anways.  Rs can change under extreme temperatues by up to 3x. The FAST estimator would give incorrect values if you still had an Rs three times lower than actual.

    Flux: The flux is always measured Online while the motor is running, so having a "real" value isn't important.  You do want to make sure that your value in user.h is within +/- 40% of the real running value though. It's basically a window of operation.

    Ls: Inductance is different than the others....there isn't a single inductance value. Inductance changes with speed and load so there isn't a "real" value.  Inductance also differs in the D and Q reference frames depending on saliency of your motor (this is why we offer a USER_MOTOR Ls_d and Ls_q variable, you can set these different if you know the value).  There are some applications that are so concerned with efficiency that they evaluate their Ls values over all sorts of loads and speeds and actually update these values from a look up table on the fly.  This is if you need to eek out every last % of efficiency and torque.  In most applications this isn't necessary.  What you should keep in mind is that it is better to have an Ls value that is too low (slightly lower efficiency but better stability) than too high.

     

    Aj Thomas said:
    2.) Once the motor parameters are identified (by some means) are only the Kp and Ki parameters that needs tuning.

    The current controllers (Id and Iq) have their Kp and Ki gains set automatically based on the R, L, and control frequencies.  If you would like to change them you can test your system with step input torque commands and see if the response fits your needs. In geneeral, this default tuning - combined with our angle compensation to deal with control loop delays at high speed (only available when running the control system from user code, not from ROM) - works very well. Some customers use their own current controllers...there are benefits to doing things like cross coupling....if this is your expertise, take advantage of that knowledge.

    With InstaSPIN-FOC you are responsible for tuning your speed regulator. We give you a PI speed controller example. It is un-tuned.  It is often likely that you will need to "gain stage", this means having a look - up table that your state machine uses to set new gains for the speed controller at different operating points (low speed, high acceleration, high speed, field weakening points, etc.).

    If you use InstaSPIN-MOTION you can use the SpinTAC speed controller (replacing the PI) which typically only requires 1 gain for the entire operating range (we usually have to reduce this gain as we go into deep field weakening).

    Aj Thomas said:
    3.) Are the parameters identified consistent for the motor over the Motor specified Speed range. I wanted to understand if the Motor identification part needs to be redone if i want to run the motor conistently at whole range of minumum to maximum motor rated speed.

    For a given motor you do not have to update the motor parameters more than the 1 time.  In your embedded code you may choose to have a motor ID process that you run for pairing with a motor...or if they will always be with the same motor that you have spec'd you should be able to just use the RsRecal / RsOnline feature and get consistent performance.

    Aj Thomas said:
    4.) For FOC how to determine the lowest operating speed that can be supported by TI solution + Motor. What HW parameters matter and to what proportion.

    For sensorless FAST operation the lowest speed is primarily a function of the Flux of the motor as a % of the ADC and IQ Voltages.  The larger the Bemf produced by the flux, the lower speed you can go.  You will also see an incluence from the load.  Higher load will give larger current signals which is a benefit for tracking at low speeds.  It is also influenced in practice by your speed controller.  This is another area where the SpinTAC controller is superior to the PI, it is much easier to get the premium low speed performance.

    Aj Thomas said:
    5.) At manufacturing stage what is the suggested course for Motor identification parameters.

    This depends on what your product is....for an air conditioner application they typically have the Rs, Flux, and Ls compiled in the user.h, and then in system they run RsRecalc or RsOnline and don't change the other values at all.

    If you were selling an AC Drive to be used with multiple motors you would have to have a learning phase and store these values in an external EEPROM or user OTP (there is no on-chip EEPROM on Piccolo devices).

     

     

  • Thanks Chris . You have nailed all my questions.

    I am evaluating both Instaspin motion and FOC for designing drive for a  range of motors from single manufacturer. And i think the lookup table approach will help me in manufacturing.

    Best regards

    Aj