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/TMS320F28069: incorrect RPM from controller

Part Number: TMS320F28069
Other Parts Discussed in Thread: MOTORWARE

Tool/software: Code Composer Studio

Hi,

I'm using InstaSpin foc motorware for my ACIM Motor. We identified motorparameters with the example lab2a with the hvkit_rev1p1.

My motor-rpm has to be 12'000 so 200 Hz (1 pole-pair). I've read, that the measured phase current correspond with the electrical speed of the motor. My problem is, I can not measure the real RPM of the motor external with any encoder, because the motor is a closed system.

The estimated motor speed seems to be incorrect, when compared to the phase current.

With no load, the estimator gives 12'000 RPM back, but the measured phase current with an oscilloscope shows about 215 Hz (12900 RPM)

With load on the motor its exactly the opposide. I measure about 180 Hz (10800 RPM) but the estimator gives back a value around 9000 RPM. With load I also have the problem, that the speed is decreasing, so the controller cannot control the motot correctly to the set speed.

What could cause this problem?

Another question is, how is the speed measured by the controller without any sensor? I cant find that information in any documentation.

Best regards,

Dani

  • Typically when we see an issue like this, we first want to check if the identified parameters are correct, as they are used in the FAST calculation for speed. Is your motor low inductance? What were the identified parameters?

    The speed calculation is performed by the estimator from the current and voltage feedback. There is no public documentation on the estimator algorithm as it is proprietary code

    Sean
  • So my motor is low inductance I think.

    The parameters are:
    - ACIM Motor
    - Number of Polepairs = 1 -> 2 poles
    - Rr = 3.12 Ohm
    - Rs = 5.5 Ohm
    - Ls_d = Ls_q = 11.59 mH
    - Rated Flux = sqrt(2/3) * 200V / 200 Hz = 0.8165
    - Magnetizing Current = 1.2 A
    - Max Current = 8 A
    - Flux Est Freq = 5 Hz

    Dani
  • Hi Dani, sorry for the delay in response. Please do the following:

    1. Ensure the pole pairs is as you expect to get the correct speed feedback.
    2. Set a correct rated flux to identify the motor parameters using below equation.
    Rated Flux = sqrt(2/3) * (line to line rated voltage) / rated frequency
    The rated voltage and rated frequency should be get from motor datasheet.

    If you're sure you've the pole pairs set correct, try item (2) and report back

    Sean
  • Hi Sean,

    We checked the polepairs much time, also disassembled the used motor, to view the conductor coils. Whe are pretty sure, that there is only one polepair.

    To ensure that, we drived the motor with another inverter and the correct speed is applied to motor, as we expect.

    As I wrote in my last post, the rated flux is: sqrt(2/3) * 200V / 200 Hz = 0.8165. From the datasheet the line to line voltage is 200 V and Frequency is 200 Hz (12'000 RPM) with 1 polepair.

    We tried identifying motor a plenty of times, also with different rated flux, but nothing works, to drive our motor at correct speed.

    Dani

  • Dani

    I think this issue might be related to the issue that we are diagnosing with Stefan here: e2e.ti.com/.../2784322

    I think there is some issue with rated flux calculation. As I mentioned in the other post, we typically see rated frequency for ACIM around 50.0 to 60.0 Hz. 200.0 Hz seems high, and is perhaps the maximum frequency from the nameplate info

    If you are using the same motor as Stefan, it is imperative to have the correct identified parameters in order for the estimator to produce the correct RPM. Please have a try to identify the values and see if that corrects the issue with the RPM reading

    Sean
  • Hi Sean

    Yes it is the same motor as stefan has. He tries to identify the motor with InstaSpin hardware and I write the complete application firmware for our own hardware.

    The problem is, there is no datasheet from the motor, because our client deliver the motors and he has no information about the motor.

    Anyway, I tested our inverter now with different Rated Flux under loaded motor condition. I can't see any difference in controling with a Rated Flux with 200 V and 200 Hz and at 200 V, 60 Hz. But what I can see, when changing Magnetizing Current from 1.2 to a smaller value (0.8, 0.6 or 0.4), the motor is controlled better.

    I set now the Speed to 10'000 RPM. As you can see, The speed from the estimator is arround 10'000 but measured speed by current waveform says arround 12'000 RPM. Following picture is with a magnetizing current of 1.2 A and a Rated Flux with 200V, 60Hz. The controller is very slow in speed controlling.

    At this picture, the Magnetizing Current is 0.5 A and set speed is again 10'000 RPM. Rated Flux is again 200V, 60 Hz. The controller is much faster in speed controlling.

    As I can see at heavy load, the speed is decreasing and parameter Vs is at limit of 0.67 (overmodulation at 0.67). But the motor current limit is not reached.

    I also tried Rs recalculation and Rs online calculation, but controlling is getting worse than. Trying to identify motor parametes gives the values I posted before.

    Is there anyone from TI arround Switzerland, Germany or Austria I could call to get some support? We are having much problems and have to get some results that work now.

    Best regards,

    Dani

  • Dani

    If you have a TI sales representative you can contact, they would be the resource that could help get you help locally. I do not have any resource available in that area that I can contact as our team is local to Houston (and is a totally different portion of the business).

    I am out of the office, so I've referred your post to my co-worker and asked him to respond

    Sean
  • Dani

    We were able to locate an ACIM motor in our lab that has a maximum frequency of 340Hz. We were able to drive it to 200Hz without issue as a sanity check on our end. Let me ask now:

    1) Are you using a custom hardware board? If so, you may need to check that the current and voltage sampling circuits are performing as expected
    2) Since you aren't able to find the rated/base frequency, are you able to hand-tune the rated flux to help in identifying the motor parameters?

    Sean
  • Sean

    We are using our own hardware board with an IGBT module "STGIPL20K60" and drive it with 18kHz PWM. We just customized the parameters in user.h for proper current and voltage scaling.

    As I see, voltage and currents measured are correct. But what is the most simple way to check, if currents are correct?

    Just to say, identifying motor parameters is done with the hvkit_rev1p1 from TI and not with our own hardware board.

    We also tried to identify motor parameters with different rated flux, but didn't see huge differences in motor parameters.

    As I wrote in my last post, value Vs is at limit of 0.67 (overmodulation is at 0.67) very fast under a small load of motor. The identified magnetizing current with our motor is at 1.2A but with this value, Vs is at limit very fast. When I set magnetizing current to 0.6A, Vs is at limit later with more load on motor. With a scope, I see that PWM is opening more (overmodulation) during heavy load, as I expect.

    Dani

  • I captured the raw ADC measurement (12 Bits) of Phase 1 Current and sampled 2'000 samples (18kHz PWM) with the running motor at 10'000 RPM set.

    The first picture is with no load (freerunning) and current measurement looks good.

    The second picture is at heavy load:

    Is it normal, that current measurement has such a curve? Or is this because of overmodulation?

  • We would recommend that you re-run motor ID with your custom hardware and cross-verify with the results from the HV kit as a sanity check to ensure your voltage and current feedback networks are working as expected. Labs 1b and 1c in Motorware 18 are also provided for HW verification if you find that motor ID does not work as expected. Can you try to re-run motor ID so we can mark any hardware issues off the list?

    Thanks
    Sean
  • I identified the motor now with our own hardware. All parameters are almost the same as with the hv_kit from TI.

    I also checked the code within Lab1b and Lab1c, but we dont have the PWMDAC signals available on our hardware. But I think, getting the same results in motor identification with our own hardware compared to hv_kit, resluts in correct current and voltage reading.

    We also tried to run the motor with hv_kit under load and we see the same results as with our own hardware, that controller is not able to hold speed.

    For identification, I used lab2d (with fpu), because you suggest to stefan, that we should use lab2c for low induction motor. What is the limit to say the motor is low induction (our motor has an inductance of 11mH)? In lab2c for low induction motors the PWM frequency should be between 30-45 kHz. With our IGBT module, the maximum frequency is 20kHz. Could that be a problem for controlling?

    I have another question to the scale-factors of current and voltage:

    The voltage and current in gAdcData is as described in "per-unit". But what is this "per-unit". When the value is 0.1 is this 10% of the maximum readable current/voltage? And is this maximum the USER_ADC_FULL_SCALE_CURRENT_A or USER_IQ_FULL_SCALE_CURRENT?

    So what could we do next, to get the controller work?

    Dani

  • You are correct, if motor ID works well with your custom hardware then there is no reason to run labs 1b and 1c. As for low inductance motor ID, we usually consider Ls values in the single-digit micro Henry range to be low inductance motors, so 11mH is a good value for use with lab2b or lab2d. If your IGBT module max switching frequency is 20kHz, then your PWM switching frequency is also constrained to this value.

    The per-unit value for current/voltage is defined with respect to the IQ full scale variables set in user.h. ADC full scale is used to map the ADC result value to the hardware feedback circuit max value.

    For ACIM, the estimator reports back the mechanical speed, and you are trying to correlate the phase current frequency to this speed but that is not accurate. ACI motors have slip due to their construction, so the phase current electrical frequency will always be higher than the value the estimator reports. You need to account for slip, which is not an easy calculation as the slip depends on motor speed and load. At no load, the value will be skewed less due to less slippage, but at high load the slip will be higher, furthering the error between what the estimator shows and the calculated value based on the phase current frequency. The most accurate way to correlate the ACIM speed and the estimator feedback will be to use a physical speed sensor, such as a laser speed detector or encoder.

    Still, the discrepancy between the phase current frequency calculated RPM and the estimator RPM is large, and may mean there is some issue with the feedback. Without the correct base motor frequency, there will be an issue to calculate the correct rated flux. I'm assuming this could be a part of the issue with the difference.

    The current waveform does not look correct when it is loaded. What is the peak current? Have you checked the voltage waveform to see if it's distorted? Perhaps it is an issue with variable overflow, though I am not sure yet

    Going back to your question about the magnetizing current - while it is ok to reduce the identified value a bit, halving it is not recommended. Your torque output will be greatly reduced. It seems that you are trying to achieve a higher DC bus utilization to achieve a certain RPM, but we would recommend that you either increase the DC bus if possible, or use overmodulation instead of reducing the magnetizing current by half

    Sean
  • Hi Sean

    Thanks a lot for the answers.

    In our appication it is unfortunately not possible to use any sensor for speed feddback.

    The peak current is about 5 A. The voltage feedback looks good and is not distorted. I think a variable overflow is not the problem, because as you can see, the raw adc values are arround 1300-2500 in current measurement, max value is 4095 (12bits). I need to check, if signal at MCU input is the same with a scope.

    Increasing DC Bus is also not possible, at our hardware is no PFC, its a simple rectifier with capacitors from 230VAC input. Overmodulation is already enabled an set to its maximum of 0.67. We can see the overmodulation effect with scope in PWM signals, when motor is loaded.

    Dani

  • Are you able to use a tachometer in the lab to verify the speed of the shaft to correlate to what you're seeing in the CCS watch window as reported by InstaSPIN? This may be a better way to determine if the feedback is correct in a lab setting.

    Sean
  • Hi Sean

    The motor is used to compacting cement, thats the reason why the motor and shaft is closed and not accessible. The motorshaft has an imbalance which causes vibration to compacting cement.

    Our Motor is a closed system, there is no access to the shaft or any rotating point of the motor. But we were able to drill a hole to one motors case, to measure speed with a sensor. This is unfortunately only possible in no load operation, but the speed values are then correct.

    Could there also be an issue with the current reconstruction function? I have seen two different calculations in different labs. I commented the code I found in an other lab. Which of them sould I use with overmodulation?

    void runCurrentReconstruction(void)
    {
        SVGENCURRENT_IgnoreShunt_e ignoreShuntThisCycle = SVGENCURRENT_getIgnoreShunt(svgencurrentHandle);

        // run the current reconstruction algorithm
        SVGENCURRENT_RunRegenCurrent(svgencurrentHandle, (MATH_vec3 *)(gAdcData.I.value));

        gIavg.value[0] += (gAdcData.I.value[0] - gIavg.value[0])>>gIavg_shift;
        gIavg.value[1] += (gAdcData.I.value[1] - gIavg.value[1])>>gIavg_shift;
        gIavg.value[2] += (gAdcData.I.value[2] - gIavg.value[2])>>gIavg_shift;

        if(ignoreShuntThisCycle > use_all)
        {
            gAdcData.I.value[0] = gIavg.value[0];
            gAdcData.I.value[1] = gIavg.value[1];
            gAdcData.I.value[2] = gIavg.value[2];
        }

    //  SVGENCURRENT_MeasureShunt_e measurableShuntThisCycle = SVGENCURRENT_getMode(svgencurrentHandle);
    //
    //  // run the current reconstruction algorithm
    //  SVGENCURRENT_RunRegenCurrent(svgencurrentHandle, (MATH_vec3 *)(gAdcData.I.value));
    //
    //  gIavg.value[0] += (gAdcData.I.value[0] - gIavg.value[0])>>gIavg_shift;
    //  gIavg.value[1] += (gAdcData.I.value[1] - gIavg.value[1])>>gIavg_shift;
    //  gIavg.value[2] += (gAdcData.I.value[2] - gIavg.value[2])>>gIavg_shift;
    //
    //  if(measurableShuntThisCycle > two_phase_measurable)
    //  {
    //      gAdcData.I.value[0] = gIavg.value[0];
    //      gAdcData.I.value[1] = gIavg.value[1];
    //      gAdcData.I.value[2] = gIavg.value[2];
    //  }

      return;
    } // end of runCurrentReconstruction() function

    Dani

  • Which lab are you using? Motorware 18 lab10a has the newest implementation of current reconstruction, which is the version we advocate using. The version in MW18 limits the modulation index to ensure only 1 shunt is ignored at a time to improve robustness. These changes should be shown in labs 10a and 10c as of MW17

    Sean
  • Hi Dani, any update here? If not, I'll close this thread for now

    Sean
  • Hi Sean

    We are using lab10c from motorware18 library.

    Dani

  • We recommend you use lab10a for the most up-to-date current reconstruction example

    Also, it is good to see that the measured speed is similar to the feedback speed at no load.

    Going back to your first post, I am thinking again about your issue not being able to spin to the desired speed under heavy load. If your VsOut vector is close to the overmodulation index (0.67 in your case), and you cannot increase your DC bus, your only other option is to use field weakening to decrease Id, which can give some additional speed but decreases torque output. Have you tried running the field weakening lab?

    Sean
  • Any update here? If not, I'll close this thread for now

    Sean