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.

CCS/TMS320F28054F: Instaspin/FAST EST_getTorque_Nm insight

Part Number: TMS320F28054F


Tool/software: Code Composer Studio


Hi,

Can TI give a bit more insight into the error of the EST_getTorque_Nm() function of FAST?

The reason for this request is that we use this function in a product that is calibrated and contains a correction based on the calibration data.

In a future update we want to switch over to the USER_computeTorque_Nm() function, which is more accurate.

But to achieve this, we must perform a correction for the older products.

Thanks,

Johan

  • As you found in the project, you might use USER_computeTorque_Nm() function to get the mechanical torque of the motor that is estimated using the torque equation in the d-q reference frame, Te=(3/2)*(Flux*iq-(Ld-Lq)*id*iq). The EST_getTorque_Nm had a coefficient converting error to calculate the torque, that will not get a correct torque. 

  • We would like to know exactly what the issue is so we can make a correction based on that knowledge.

    For this correction we also need to reverse the function (torque to q-current with the inputs of flux, d-current and Ls-dq).

    At this moment we are not able to do this because we don’t know what causes the error.

    We suspect an issue with the flux parameter but some clarification would be welcome.

  • I did some experiments by comparing the results of both functions, EST_getTorque_Nm and USER_computeTorque_Nm.

    First I had to fix the gTorque_Ls_Id_Iq_pu_to_Nm_sf scaling factor, which in our case should be 328.1 (which is way too large for IQ24) so it got saturated at +127. Strange that it is not detected by USER_checkForErrors but that's a different story. By the way this is all MW18.

    Now about the torque differences.
    No differences were found in the torque output of both functions as long as the d-axis current remains zero.

    But if a negative (or positive) d-axis current is applied then a deviation becomes noticeable. And that while the flux remains the same and the DQ inductances are set the same, so Ld - Lq = 0.

    With the torque equation in mind this led to the suspicion that there is a difference between Lq and Ld values in the EST_getTorque_Nm function. But another thing that surprised me is that the deviation is influenced by the frequency if the d-current is unequal to zero.

    By adding an extra term to the torque equation in USER_computeTorque_Nm it was possible to create the exact same output as EST_getTorque_Nm.
    The (faulty) equation of the electromagnetic torque now looks like this: T = 1.5*PP*Iq*(Flux+(Ld-Lq)*Id) + 2*PI*f_el*Id*k

    Where:
    - f_el is the electrical frequency in Hz
    - k is a constant value which in our case is 0.1.

    This is true as long as Ld = Lq. It could be that (Ld-Lq)*Id is not part of the original equation and that k is derived from (Ld-Lq) but that a bit of a guess.

    So, it seems that EST_getTorque_Nm not only has a coefficient converting error but also uses a slightly different equation. I hope that Ti can confirm whether this is correct so that we can use it to compensate for our older products.

  • That's why add USER_computeTorque_Nm() as a workaround in the project, so please use the USER_computeTorque_Nm() directly.