• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 779 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.

TMS320F28035: InstaSPIN SPEED_MEAS_CAP RPM does not match mechanical RPM

Gary H
Expert 1855 points
Part Number: TMS320F28035
Other Parts Discussed in Thread: INSTASPIN-BLDC

I am using the InstaSPIN BLDC to run a small 12 volt motor. I am using the SPEED_PR_MACRO to calculate the RPM of the motor. From what I can see this just counts the number of electrical rotations within a certain time and calculates the RPM. The speed RPM output from this fucntions seems to be very noisy, so I filter it in order to get an averaged value. The RPM seems to be with 20 RPM most of the time for some motors, but around 1400 RPM on some motors the RPM reported by the software is 1400, but the mechanical RPM of the motor is around 1300. All the motors tested are the same model motor, but I guess slight differences in the inductance from motor to motor can cause different RPM error.

I am just wondering is why there is so much noise on the speedRPM and what can I do to get the speedRPM to match the mechanical RPM? Is there a better way to measure the RPM?

Below is the code which I believe is still the same as the example InstaSpin BLDC from the TI lab.

//while counting up we want positive speed

if((mod_dir1.Counter==5)&&(PreviousState==4)&&(mod_dir1.TrigInput))

{

speed1.TimeStamp = VirtualTimer;

SPEED_PR_MACRO(speed1);

SpeedLoopFlag = TRUE;

}

//while counting down we want negative speed

else if((mod_dir1.Counter==0)&&(PreviousState==1)&&(mod_dir1.TrigInput))

{

speed1.TimeStamp = VirtualTimer;

SPEED_PR_MACRO(speed1);

speed1.Speed = _IQmpy(speed1.Speed,_IQ(-1.0));

SpeedLoopFlag = TRUE;

}

  • 0
    TI__Expert 6965 points

    Hi Gray,

    I cannot fully understand what do you mean by "The RPM seems to be with 20 RPM most of the time for some motors, but around 1400 RPM on some motors the RPM reported by the software is 1400, but the mechanical RPM of the motor is around 1300." However, I will try to address your issue as best as I can. Please correct me if I misinterpreted your question.

    The SPEED_PR_MACRO is calculating the speed by counting the number of ISRs (20 kHz by default) it takes for the motor to run one electrical revolution. Assuming your motor has 4 pairs of poles, the electrical speed at 1300 rpm would be 86.67 Hz. Giving the default ISR is running at 20 kHz, there will be around 230 counts. If your motor is running at 1300 rpm exactly constantly, the speed output will flip between 1304.3 (count 230) and 1298.7 (count 231) rpm due to quantization noise. In another word, around the 1300 rpm speed, the resolution of speed is about 6 rpm and the result will jump in such increment. Given the fact that your motor may not run at perfect fixed speed, this could result in several tens of rpms change between two readings. I am not sure if this is the kind of noise you are experiencing.

    For the difference among different motors, I have some questions:

    1. Have you verified that the motors did run at the same speed with other speed measurement device? It is possible that the motors are running at different speed if your are running them open-loop.

    2. InstaSPIN-BLDC works by integrating the back-EMF waveform and the BEMF integration threshold (InstaSPIN_BLDC1.Int_Threshold) needs to match the value in that specific motor. This value is related to the winding inductance and rotor flux. Please look into Level 5 Incremental Build in the lab to verified that your BEMF integration threshold is properly tuned.

    Please let me know if this solves your questions. If you have further questions, please also include the board you are using and some parameters of your motor (No. of poles, etc.) Thanks.

    Best regards,

    Han

  • 0 in reply to Han Zhang6
    Expert 1855 points
    I did not proof read my sentence before sending:)
    I meant to say the RPM seems to be within 20 RPM most of the time for some motors...

    It seems with some compressors under load the noisy speed calculation feeding into the speed PID causes an error in the actual RPM to where the actual RPM is lower than the measured RPM. This causes the compressor to spin slower (over 100 RPMs) than the speed set point. I think the difference in inductance from motor to motor is enough that some motors have more noise generated by the current PID reacting to the two piston load changes. If I take the Mod6 count and generate my own speed calculation (over a 1 second period) it seems to be more accurate in measuring actual mechanical speed. I thought a simple fix would be to take my speed calculation and introduce a correction into the TI speed calculator. My speed calculation does not have to be very fast since my system has several seconds to get to the correct speed.

    Another thing I noticed about the current PID. Some times at start up my system gets a high current and the motor does not start. In this state I noticed that the current PID is doing what it is suppose to do by taking its output to Umin (-0.95). However the PWM is not responding to the -0.95. It keeps the current at a high state. If I change the current PID Umin to (0.20), the over current goes down and prevents the high current state from occurring. Its almost as if the PWM does not respond to negative numbers even though it states its range is -1 to 1. Maybe the actual range is 0 to 1. I will try to confirm this by looking at the TI source code. Maybe this is a known bug with the TI InstaSpin BLDC lab code. I am using the level 8 Cascaded example.
  • 0 in reply to Gary H
    TI__Expert 6965 points

    Hi Gary,

    Thanks for the clarification. 

    For the speed noise, you can consider adding a low pass filter in the speed feedback path. As your have a loose response time requirement, consider reducing the speed loop bandwidth.

    For the current loop controller, the output of 0.95 and -0.95 are maximum positive and negative voltage. Giving either one could yield to high current. For the start up current, since you are running the motor sensorless, there could be a initial commutation error. That may have something to do with your start up issue. There is a initial start routine, which also need to be tuned properly. Thanks.

    Han

  • 0 in reply to Han Zhang6
    Expert 1855 points
    It appears what is happening with our two head piston compressor is that the RPM of the motor is not constant with one mechanical revolution. As the piston reaches its peak pressure, on the upward stroke, the motor slows down and then speeds up as the piston starts in the downward direction where the pressure goes to zero fairly quickly. Since the TI SPEED function is calculating the speed for every electrical cycle it measures the speed of the compressor ever quarter turn. So, the speed noise is real and when fed into the PID causes a speed error. I have seen the RPM range from 800 to 1800 in one revolution with a set point of 1400 RPM. These sudden changes in RPM is causing some error in the PID.

    What I did was change the TI SPEED function to measure speed once every mechanical revolution (after 4 electrical revolutions). I then retuned the PIDs and all seems to be working great. The mechanical RPMs are within 5 RPM of the set point even under heavy load. I also think that the deference's between one compressor and the next may be due to the mechanical alignment of the motor relative to the piston shaft. This is not controlled in production and I can see that some compressors would give bigger differences in quarter turn speed depending on where the motor poles are relative to the piston location.

    Also After setting my current PID Umin value to +0.25 instead of -0.95 all my startup problems have gone away.

    I still don't understand when I would want to apply a negative PWM to my motor? I plan to dig into the PWM module next and understand exactly what a negative PWM does to my motor. I just know that whenever I force a constant negative PWM, the motor just hums and does not turn, so I would never want the output of my current PID to ever feed the PWM a negative number.
  • 0 in reply to Gary H
    TI__Expert 6965 points

    Hi Gary,

    I am glad to see that you have resolved your problem. If you does not care the speed variation within one revolution due to the uneven load of the compressor, your solution of averaging speed during one revolution is definitely going to work.

    For negative PWM, it is actually reverse voltage applied to coil, which is for reverse rotation of the motor. Since your load is compressor, it does make sense to have it run in reverse direction, hence setting the minimal output of PI to positive value make sense. Thanks.

    Best regards,

    Han