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.

DRV8213-C2-kit speed limit

Other Parts Discussed in Thread: DRV8312, INSTASPIN-BLDC

Hi, I'm using the DRV8312 Piccolo kit. Investigations with the kit motor went fine but when I switched to a Faulhaber 3564 motor I noticed a behavior I can't explain. The speed seems to be limited to around 7500 rpm even though I've set the base frequency to 333 Hz (4 poles) which would give me 10000 rpm max. I also changed the pwm frequency to 40k due to the low inductance of the motor. Do anyone have any advice to give? 

Br, Johan 

  •  Johan,

    You must look into back-emf constant (volt/rpm) parameter of motor. The speed can get limited if applied dc voltage is not sufficient to over-come back-emf of motor at higher speed; you can verify it by increasing the DC link voltage and check if motor speed increases.

    Best Regards

    Milan

    Motor Application Team

  • Hi Milan,

    Thank you for your attention.

    The back-emf of the motor is 1.521 mV/rpm. I'm using the kit power supply (24V 2.5A) so I shouldn't run into problems at 7500 rpm? I should also mention that the motor essentially runs unloaded.

  • First things to look at are voltage and current limits. Agree, your Bemf looks to be about 15V at 10K RPM if your numbers are correct, and I assume you have plenty of currrent, especially unloaded.

    Assuming your commutation is tuned correctly, using IS-BLDC without any speed or current loops accidently regulating you too low you should be able to go faster.

    One thing to look at is the voltage filter pole on the Vph sense circuits. These are actually set to ~714 Hz for use with our InstaSPIN-FOC technique, and this filter is actually a negative for IS-BLDC.  If you change this filter lower it should help (some motors it is a huge difference, some don't seem to matter).

    –DRV8312: C50, 55, 56; Currently 47nF, change to 10nF
    –DRV830x: C67, C68, C69; Currently 100nF, change to 10nF
     
    You usually only see this on motors that are set to run over 15 KRPM, but it's worth trying.
     
    And when you say it doesn't run faster....does it just stay at 7500 RPM or does it crash?  If it crashes it could be due to current ripple tripping the DRV device. In this case you will want to add current control and if it is a very low inductance motor you may need to increase the PWM Frequency.  Especially with BLDC control on these small motors you often see the drivers they sell running at 60 KHz.
     
  • Thanks for the comprehensive answer Chris!

    I realize I gave too little information as I'm running the sensored trapezoidal control project with access to both Hall and encoder feedback.

    I actually managed to reach 10 000 rpm by increasing the control loop interrupt frequency. My PWM frequency is 60 kHz (not 40 as I stated in my first post), but I still thought that a 40 kHz control loop would be enough?

    Maybe it is related to the quite substantial jitter I observe on both the Hall and encoder pulses which make the speed variable fluctuate with a couple of 100 rpm around the target speed. I played around with the P and I constants but without luck. Any advice?

  • Ahh, yes, if using hall sensors it could certainly be due to jitter on the hall signal or a lag in the controller. Note that there is a delay at high speeds from the angle registered by the hall sensor (or even SW sensors for that matter) and where the rotor has moved to by the time you output a control signal. This is a sample to output delay control problem that you will face regardless of the feedback method. You will need to do some angle compensation (basically telling the control system that you are X-degrees further ahead).  With sensorless InstaSPIN-BLDC this is actually pretty easy to do, you can just reduce the Vth variable to switch earlier, called Commutation Advance.

  • Thanks Chris!

    I tried to optimize the time between sample and output (i.e. minimize code between HALL3_READ_MACRO and BLDCPWM_MACRO) but that didn't help. Instead I found that a delay of ~3µs (100 kHz interrupt freq) before or after the  HALL3_READ_MACRO/BLDCPWM_MACRO block allowed me to increase the speed beyond the previous 7500rpm. But I can't explain why that helped...? Also, the jitter is still there.

  • "(i.e. minimize code between HALL3_READ_MACRO and BLDCPWM_MACRO) but that didn't help"

    I wouldn't expect this to help. You are talking about < hundreds of CPU cycles. The issue mentioned is in the ratio of Motor Frequency at high speed (say 2 KHz)  to the sample/control frequency (10-20 KHz typcially).

    You likely need to commutate sooner than you actually are, so you should work this into your software somehow.