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.

Maximum Commutation Speed 28096 FOC

Other Parts Discussed in Thread: DRV8301-69M-KIT, DRV8301, BOOSTXL-DRV8301, LAUNCHXL-F28027F, LAUNCHXL-F28069M, MOTORWARE

I need to drive a 22 pole motor at at least 8,000 RPM using FOC (and field weakening if necessary).  The motor is a BLDC motor: Joby Motors JM1 running at 90V, 150A.  I need to run a torque control loop on the motor which will be controlled/set by an outer speed control loop.  My concern is if the FOC hardware can commutate and control well at this high commutation rate.

Thanks,

Tim

  • That's just under 1500 Hz,which isn't a problem for the algorithms. We have run over 4000 Hz with InstaSPIN - FOC. 

    The area to concentrate on will be the current sensing. A motor this high speed and this torque probably has a very low inductance. If you use low side current shunt measurements like our kits it can be challenging to get nice current measurements due to the current ripple every time you switch the FET. However, with this high of currents the shunts get pretty expensive and introduce quite a bit of losses, so most people would be using in phase current measurements like LEM sensors. This will make getting good current information easier,but instead of taking a single value it would be helpful to do some averaging. 

  • Hi Chris,

    When you state that you managed to run a motor over 4kHz, can you please state also some system parameters, i.e. frequency of current and estimation loops, flux, inductance and resistance of the machine..what is the type (PMSM etc.)

    IMHO, running a 4kHz motor is a very difficult task, so if you state the parameters, then for us users it will be easier to understand what type of motors can be controlled in such a high speed...

    Thanks a lot

  • Hi Chris,

    Thanks for the thorough and quick response.  You say that the current sense line(s) might need averaging. This averaging or filtering will build in delay to the current response.  Is this something I should be concerned about?  What are the reasonable limits before this delay becomes problematic to the control loop?  Are there any documents I could read that would be helpful in knowing how to configure the system parameters?

    Also, what hardware would you recommend I purchase to test out the tools and the algorithms?  I would like to try running your algorithms on some standard/stock RC outrunners for starters.  I currently have the  DK-LM4F-DRV8312, but it appears that that is obsolete and uses a different processor, not to mention its lack of drive.  Your recommendations as to the best hardware to get started with would be appreciated.

    Regards,

    Tim

  • Mojo,

    The motor we ran over 4 KHz is a high speed motor used in a small pump.  8 poles, so 4 KHz = 60,0000

    These motors have R / L > 25 KHz and <10uH inductances. Using DRV83xx EVM with low side current sampling the current waveforms look pretty raged, especially when you are only updating ~7 times per cycle at high speed.  If you want to make the waveforms look better it really helps to add 50-75uH of inductance at the inverter, before you take the phase voltage measurement and go to the motor phases.  Then you get pretty reasonable currents.

    Yes, you have to run your current controller and estimator at high frequency. The current control rule of thumb is always 7 minimum and at least 10x is better. But our estimator has a minimum of 8x the max frequency.  So for 4 KHz you should run the estimator, and hence the current controller, at 32 KHz minimum. 

    We actually ran at 30 KHz for both and it still worked fine.  However, that' using about every MIP from our 90 MHz device. So is it realistic for a product?  I'd say no.

     

    But 1.5 KHz motors are completely achievable for closed loop current control FOC, and InstaSPIN-FOC especially.

    Tim,

    "This averaging or filtering will build in delay to the current response"

    Not necessarily.  Ideally, if you have phase current sensing you can take many samples continuously, and then when your control interrupt occurs you simply create an average for your algorithm to use (rather than a single sampled event near the center of your low-side on time).  The estimator and current control run as is...I'll see if we can add some detail to this...we have a few boards we've built up using LEM sensors.

     

    Tim VanderMey said:
    Also, what hardware would you recommend I purchase to test out the tools and the algorithms?

    For your motor there isn't anything in the right power level. Closest is DRV8301-69M-KIT at 60V and 40A peaks. This will get you started.

    Tim VanderMey said:
    I would like to try running your algorithms on some standard/stock RC outrunners for starters.

    You'll be able to run some of these motors, but few will have an "Insta" experience. For one thing, most of the RC outrunners run on much lower voltage, so the 66V scaling of the DRV8301 EVM is a problem, you throw away too much resolution when using 6-24V motors.  The BOOSTXL-DRV8301 inverter is much better for this purpose, but only does 10A continuous.  The DRV8301 EVM also picks up switching noise on the current feedback at higher duty cycles (somewhere over 0.95) which adds another problem.  The BOOSTXL-DRV8301 is much better in this respect.

    The other issue with these motors is some (most) of them have absurdly low inductances, with really nasty current ripple.  The lower the KV the better they run with InstaSPIN-FOC.  We can run any of them, but some are more finicky than others....and the higher the KV there becomes a real question if a closed loop current control approach is the best solution.  Probably not.  You'll notice we aren't really marketing / promoting InstaSPIN-FOC for these type of hobby motors.  It can be very beneficial for lower KV / higher torque motors used in UAV / Drones, but I want to make it clear that I wouldn't try to make a universal RC ESC out of this solution....

     

  • Hi Chris,

    The BOOSTXL should work fine for our initial experimentation and testing of the FOC code and algorithms.  I noticed it is made to work with the LAUNCHXL-F28027F.  Initially I was thinking of targeting another processor, but if the 28027F will do the commutation job that should be fine in our application.  Can the 28027F handle our 1500Hz-1650Hz top speed range with ease?  If so I will get the board set on order immediately.

    Any additional information and examples that you can give me regarding using current transducers would be most helpful.  Also, before we design the high power inverter, I would like to further investigate the issues that your raised concerning the current waveform.  In order to do that I am going to ask the vendor (Joby Motors) for some of the motor parameters - the data on their website is very sparse.  I know the Kv of the motor (90), and I will ask them for winding resistance and winding inductance.  Are there any other parameters that I need to know that would be helpful to get a feel for what we are up against?

    Thanks,

    Tim

  • Tim VanderMey said:
     I noticed it is made to work with the LAUNCHXL-F28027F.  Initially I was thinking of targeting another processor, but if the 28027F will do the commutation job that should be fine in our application.  Can the 28027F handle our 1500Hz-1650Hz top speed range with ease?  If so I will get the board set on order immediately.

    We are making a LAUNCHXL-F28069M as well, but having an issue getting some components....it will be about 3 months before they are available.  What device were you looking at?

    Yes, for 1700 Hz you need to run run current control and estimator at 1700 * 8 = 14 KHz. + You are using about 45 of 60 MIPS at this rate. 

    Tim VanderMey said:
     I know the Kv of the motor (90),

    I've noticed that when people spec Kv they sometimes are actually specifying V.

    For example, an EFLITE 700 series motor says 500 Kv, but what they really mean is 0.5 Kv, meaning 500 RPM per Volt.  So with 50V you get 25 KRPM.  Same for EFLITE 420 3800 kV. That is really 3800 RPM per volt

    So if your motor is really spec'd like this, 90 RPM per volt really isn't that high....but you have many more poles, so your electrical frequency is still quite high. 

     

    if you ID the flux (V/Hz or calculate from Wb if given in a spec; V/Hz = Wb * 2 * pi) you can use that to get a better sense of maximum. for example, with a 24V motor that has 0.01 V/Hz of flux

      

    Tim VanderMey said:
    Are there any other parameters that I need to know that would be helpful to get a feel for what we are up against?

    If they give you Rs, Ls, Flux (everything we ID :) ) and poles you'll know everything you can know about this motor.

     

  • Hi Chris,

    I was initially targeting the 28069M, but if the 28027 will do the job on the commutation front, I can fill in with that for the time being.  I can't wait 3 months for the 28069 demo board.

    Yes, the 90Kv for Joby Motors means 90rpm/volt.  The motor is run at 90V nominal voltage, yielding 8100RPM.  The motor has 22 poles which gives us our ~1500Hz.

    I need a little clarity on what you mean by the flux parameter (sorry for my ignorance here).  Isn't flux dependent on the current in the stator?  Are you looking for the flux at a particular torque/current?  If there is a document that you can point me to to set me straight that would be fine as well.

    Thanks,

    Tim

  • Tim,

    Flux is the bemf produced (volts) at a given a frequency (Hz). It is usually specified in Webers (Wb). This is something we ID.

    From my above equation you can pretty much calculate your flux.

    81 KRPM / 90 V * sqrt(3) = 1 / flux

    Flux = 0.0064 V/Hz

    This is REALLY low. 

    And actually, if this is true this is going to be a problem....There is a flux measurement lower resolution limit with the settings of our algorithms.  To make the range low enough you are going to have to run the estimator at a much higher frequency...nearing 30 KHz.  This can be calculated in our spreadsheet

    C:\ti\motorware\motorware_1_01_00_13\docs\labs

    at cells E17 and H17.

     

    For this motor you aren't going to be able to do much with BOOSTXL-DRV8301, so i would suggest just getting DRV8301-69M-KIT.  You can run at half voltage and should get half the speed with no load....minus a bit as the current sampling may give you issues at the high end.  It's enough to give you a good start before you build your own HW.

     

  • Hi Chris,

    I was planning to use the BOOSTXL to experiment on much smaller motors.  However, given the potential need for a higher speed estimation loop (more MIPS) and the fact that the the DRV8301-69M-KIT can actually spin our monster target motor (albeit under very low load and low speed), I will purchase that unit instead... if it can run at the required rate.

    Regarding the required rate, I have a question regarding your above calculation. Where did the 81KRPM come from?  The motor maximum speed at 90V is 8.1KRPM.  Is the factor of ~10 due to the 22 poles?

    Regards,

    Tim

  • Good catch!!

    That makes more sense :)

    The flux limit isn't a problem at all with 0.064 V/Hz expected.  You'll have plenty of headroom and can run control and estimator at 15 KHz.

    Yes, go with DRV8301-69M-KIT

  • Why TI doesn't integrate FAST in one of the Delfinos (preferably dual core)... then we won't have to count MIPS and just run everything at 100khz...
    16bit dual ADCs.... all communication interfaces possible.... what a nice dream for the control engineer...

  • we would do that if every application could pay for a Delfino :)

    for now we are focusing on the lower end part of our portfolio for InstaSPIN (which is the mid end of the MCUs for motor control).

     

  • Chris - Yes, this thread, but I figured it was closed/answerd. Kurt



    ChrisClearman replied to Maximum Commutation Speed FOC, JM1 motor.
    look at gMotorVars.UserErrorCode
    take that name and look in user.c for the logic that is setting the error

    typically you would set the USER_MOTOR Rs, Ls_d, Ls_q, and Flux to (NULL) until after you have successfully ID'd the motor...this way you won't get Errors.


    Was there an original thread you are referencing?