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.

Sensorless current control but sensored speed control

Our application requires approximately 100:1 speed turn down (2krpm->20rpm) using a 4 pole AC induction motor.    I’ve experimented with SpinTAC sensored (lab 12b) using a 2000 line quadrature encoder and achieving 100:1 turn down with good speed accuracy and regulation is not a problem.

Then I experimented with InstaSPIN sensorless.  As you would expect with sensorless the accuracy at low speeds was not as good.  A set point of 20 rpm may result in a motor speed of 30 RPM.

It is not always possible for us to have a high resolution encoder on the motor, but we always have available a low resolution encoder (120 line, not-quadrature).   Our application is continuous (not positioning) and responses to speed set point changes does not need to be very fast.

Does it make sense to use FAST for sensorless current control, but encoder speed (filtered) for speed control?

Would you expect this to improve low speed accuracy over FAST?

I've started looking at modifying QEP and CTRL_doSpeedCtrl() for this change.  Does anyone have experience doing this or know of any pitfalls?

Thanks.

  • "A set point of 20 rpm may result in a motor speed of 30 RPM."

    When you say 20 RPM, you mean the rotor is actually running at 2000 RPM (66.66 Hz)? or do you actually mean 20 RPM at the rotor (0.66 Hz)?
  • Hi Chris,
    I mean 20 RPM on the rotor.

    Using AC motors rated ~2000 RPM we need a speed operating range from 2K RPM to 20 RPM (100:1 speed turn down).

    With lab 12b using a 2K quadrature encoder this was possible. With the encoder and a speed set point of 20 RPM the motor stayed between 20 +/-1 RPM both unloaded and fully loaded. For the same test sensorless the motor bobbled between 25-30 RPM unloaded, and 43-46 RPM fully loaded.

    We won't normally have available the 2K encoder, but we will always have a 120 line encoder. My questions are about using the 120 line encoder to close the speed loop instead of the FAST speed estimate.

    Thanks again.
  • 0.66 Hz sensorless is tough. You certainly won't get 100% torque, but possible you could still get enough torque depending on your application. To do this you need to have correct parameters, you need to run RsOnline to update Rs continuously (Rs is dominant at low speeds), and you need a very stiff speed controller (SpinTAC works better than a PI controller).

    Running 0.66 Hz with a sensor is much more achievable. You just need to have appropriate resolution for your encoder and proper alignment/calibration of the mechanical to electrical angle.

    "Does it make sense to use FAST for sensorless current control, but encoder speed (filtered) for speed control?"
    You're asking if it would help to only use the encoder for the speed feedback but still use FAST for the electrical angle? No, the encoder mechanical angle should be able to be used provide a more stable electrical angle at 0.66 Hz than FAST. If you have the encoder, use it.

    However, I guess your real question is if at 0.66 Hz FAST is better than a 120 line encoder? That's harder to say....for many motors I believe the answer will be Yes, but I can't say for certain with your system.

    "For the same test sensorless the motor bobbled between 25-30 RPM unloaded, and 43-46 RPM fully loaded."
    Hmmmm. This gives me more confidence. I would enable RsOnline (see proj_lab07) into your proj_lab12 and try again. You should be able to get better loaded performance. Make sure ForceAngle is disabled of course. But you won't get +/- 1 RPM like you can with the 2K encoder.
  • Hi Chris,

    I’m don’t completely understand your comments.

    You mention proper alignment/calibration of the mechanical to electrical angle. This application is an AC induction motor. If I’m correct there is no alignment for an induction motor?

    You say the encoder will give a more stable electrical angle:

    “No, the encoder mechanical angle should be able to be used provide a more stable electrical angle at 0.66 Hz than FAST. If you have the encoder, use it.”

    But you also say FAST is most likely better than a 120 line encoder:

    "However, I guess your real question is if at 0.66 Hz FAST is better than a 120 line encoder? That's harder to say....for many motors I believe the answer will be Yes, but I can't say for certain with your system."

    I don’t understand how you feel the encoder would provide a more stable electrical angle, but for many motors FAST would perform better. Can you elaborate?

    I’ll try your suggestions to enable RsOnline when sensorless. You mention “enable RsOnline into your proj_lab12 and try again”. Labs 12a,b are sensored. I am using proj_lab10b for sensorless because I’m also using over-modulation. Wouldn’t I need to enable RsOnline in a sensorless lab?

    Thanks again.
  • your incremental encoder is giving a mechanical location of the rotor. The angle used in the control loop needs to be electrical, referenced to the D axis.

    "I don’t understand how you feel the encoder would provide a more stable electrical angle, but for many motors FAST would perform better. Can you elaborate?"
    When I was answering the first question I was thinking you were using a 1000+ line encoder. At low speed it will give more accurate tracking than FAST. But 120 line may not. I don't have much experience with them, but the resolution is much poorer.

    "Wouldn’t I need to enable RsOnline in a sensorless lab?"
    Yes, RsOnline only effects FAST performance (though you could also use it in a sensored application to update your current controller gains as Rs changes). Sorry I wasn't clear. I thought your modified proj_lab12 allowed you to switch between sensored and sensorless. To test out low speed sensorless performance - and since you are using SpinTAC - I would use InstaSPIN_motion proj_lab10b.

    sorry I wasn't clear in my responses.
  • Hi Chris,
    You said "The angle used in the control loop needs to be electrical, referenced to the D axis."
    I have been specifically asking about using the 120 line encoder for the speed loop, and leaving FAST for the current loop.
    Is your statement of needing electrical angle referenced to D for the speed loop, current loop, or both?

    Looking at block diagrams, SpinTAC Velocity Control uses speed indication from FAST or an encoder, not angle.
    For example, sensorless proj_lab10b: speedFeedback = EST_getFm_pu(ctrlObj->estHandle);
    For example, sensored proj_lab12b: speedFeedback = STPOSCONV_getVelocityFiltered(stObj->posConvHandle);
    From the documentation EST_getFM_pu() returns mechanical frequency, not electrical angle referenced to the D axis.

    I apologize if my understanding of FOC is the problem.
    Maybe I am missing something?

    Thanks.
  • the electrical angle is used in the inverse park transform to calculate the modulation from the voltages calculated by the current controllers.

    "Looking at block diagrams, SpinTAC Velocity Control uses speed indication from FAST or an encoder, not angle."
    Yes, the speed controller uses mechanical frequency, but the FOC still needs electrical.

    at low RPM your 120 line encoder may not be giving you enough resolution for your speed estimate and it may not be giving you enough resolution when used to translate the mechanical to an electrical angle.
  • let me correct myself. from InstaSPIN_labs.pdf for proj_lab12b

    "For AC Induction motors, this calibration is not required, since the
    motor will always start at a zero degree electrical angle."
  • I think you should be able to use the encoder for speed feedback only and use FAST for electrical angle feedback. Chris is right in that you will face issues when running at 20rpm on the motor since depending on load FAST may not get a great electrical angle estimate.

    I think the bigger issue with a 120 count encoder will be the minimum speed resolution. ((1/(120*4))/0.001)*60 = 125 rpm is the minimum resolvable speed of that encoder, which means that you will have a very tough challenge of controlling 20rpm with +/- 1rpm of error.

    With that low of resolution, you would be better off using FAST for both control loops.
  • Adam,Chris,

    Thanks for the input.

    Per Chris's suggestion for sensorless I added RsOnline to lab 10b. It didn't improve low speed regulation, it actually seemed to make low speed regulation worse.

    I'm going to experiment with using the 120 line encoder to close the speed loop.

    Thanks again.