Difficulties running at moderately high speed

Jonathan,

Please post the Parameters ID'd

couple comments

1. What sort of current does this pull unloaded at high speeds? If less than 40A perhaps you can verify operation with the DRV8301 board to see if you can trace this back to something in your hardware.

2. IQ_FS_CURRENT_A; 700 is much too high. You should set this as just < 1/2 the ADC_CURRENT value, so something like 170A should be plenty. You are losing resolution with 700A here.

3. IQ_FS_VOLT_V; 80 is too high. With your flux you will only be generating 24V @ 1500 RPM; lower this to 30V to maximize your resolution.

4. Please set MAX_DUTY_CYCLE to (1.0); you'll notice in MotorWare _10 on Thursday that we have changed the name of this variable and it should always be set to (1.0) in the user.h file; you will only change the max duty cycle using the set functions that are shown in lab 10a

5. Is this a typo? CTRL ticks per SPEED/TRAJ tick; 20....I would suggest for your 60 KHz PWM the following:

#define USER_NUM_PWM_TICKS_PER_ISR_TICK (3)

#define USER_NUM_ISR_TICKS_PER_CTRL_TICK (1) // 

#define USER_NUM_CTRL_TICKS_PER_CURRENT_TICK (1) // 

#define USER_NUM_CTRL_TICKS_PER_EST_TICK (2) // 

#define USER_NUM_CTRL_TICKS_PER_SPEED_TICK (20) // 

#define USER_NUM_CTRL_TICKS_PER_TRAJ_TICK (20)

6. For your current control gains, I would multiply the Kp values by 4. This will take away the *0.25 that we add to initially soften the controller. This tighter current control will be needed at higher speeds.

7. Your R and L values suggest that this motor should only be able to do about 900 Hz, which is where you are seeing problems. Are you sure this motor can go as fast as you think?  If the motor ID is correct I would suggest that it will not....

HI Chris：

    my motor is identified with Rs=0.2666253 and Ls_d = Ls_q = 0.001559172, Rated flux 0.2705697, It is to say that my motor can run about RoverL = 0.2666253 / 0.001559172 = 171Hz?  What can be infoed though RoverL?

Please post the Parameters ID'd

I'm assuming you mean the results from a motor identification? If so, I've run an identification with;
R/L_f = 300Hz
Rs est current = 10A
Ls est current = 10A
Imax = 15A
Flux estimation frequency = 40Hz
(The motor I'm using has a cogging torque of around 5A)
This results in the identified motor parameters (which for Rs and Ls vary around 20% from identification to identification);
Rs = 9.3mR
Ls = 8.5uH
Flux = 0.0165

During normal operation I calibrate the sensor offsets on startup but don't perform an Rs re-estimation.

1. What sort of current does this pull unloaded at high speeds? If less than 40A perhaps you can verify operation with the DRV8301 board to see if you can trace this back to something in your hardware.

Unloaded, the motor only draws around 2 - 2.5A (at ~6000 RPM / ~800 Hz), so if things continue to be problematic I'll try this out on the dev-kit.

2. IQ_FS_CURRENT_A; 700 is much too high. You should set this as just < 1/2 the ADC_CURRENT value, so something like 170A should be plenty. You are losing resolution with 700A here.

That seems far more reasonable -- when I was originally setting up these values I misinterpreted the guideline (pg. 118 in SPRUHJ1B) for (IQ_FS_CURR_A * 2) >= ADC_FS_CURR_A by a factor of two. Thanks for the sanity-check.

3. IQ_FS_VOLT_V; 80 is too high. With your flux you will only be generating 24V @ 1500 RPM; lower this to 30V to maximize your resolution.

I'd rather not lower it as far as 30V; I'll potentially use another motor in the future with a higher flux. However, I know that I'll never use field weakening, nor will the bus voltage exceed 45V, so would a value of around 50V seem reasonable?

4. Please set MAX_DUTY_CYCLE to (1.0); you'll notice in MotorWare _10 on Thursday that we have changed the name of this variable and it should always be set to (1.0) in the user.h file; you will only change the max duty cycle using the set functions that are shown in lab 10a

Done.

5. Is this a typo? CTRL ticks per SPEED/TRAJ tick; 20....I would suggest for your 60 KHz PWM the following:

#define USER_NUM_PWM_TICKS_PER_ISR_TICK (3)

#define USER_NUM_ISR_TICKS_PER_CTRL_TICK (1) // 

#define USER_NUM_CTRL_TICKS_PER_CURRENT_TICK (1) // 

#define USER_NUM_CTRL_TICKS_PER_EST_TICK (2) // 

#define USER_NUM_CTRL_TICKS_PER_SPEED_TICK (20) // 

#define USER_NUM_CTRL_TICKS_PER_TRAJ_TICK (20)

As far as I understand what you've proposed would only change the FAST estimator to run at 10kHz, from the 20kHz I've used previously? I've monitored the execution time of the entire mainISR routine and it seems very stable at around 70% of the calling period; when I'm approaching a motor speed of 1500Hz I would have assumed that a FAST estimator frequency of 20kHz would be suitable. (?)

I am using a decimation rate of 20 for CTRL ticks per SPEED/TRAJ; which gives a 1kHz speed and current loop frequency, which I believed would be sufficient?

6. For your current control gains, I would multiply the Kp values by 4. This will take away the *0.25 that we add to initially soften the controller. This tighter current control will be needed at higher speeds.

Done.

7. Your R and L values suggest that this motor should only be able to do about 900 Hz, which is where you are seeing problems. Are you sure this motor can go as fast as you think?  If the motor ID is correct I would suggest that it will not....

Hmm, I'm aware that at speeds of around 900Hz the motor will start becoming more difficult to control, but my impression was that with a suitably high bus voltage I would be able to drive the desired motor currents regardless of this. Is this a limitation of FAST; that the rotor position cannot be estimated at speeds above the R/L pole?

I'll start doing some more testing now and will shortly add the results of these tests. Thank you for replying so quickly.

Minor update; I've checked the values generated by CTRL_recalcKpKi and calcPIgains; 

CTRL_recalcKpKi
Lhf; 6.351 uH
Rhf; 10.852 mR
RoverL; 1708
Kp; 0.086379584
Ki; 0.0854302
Kp_spd; 3.529411808

calcPIgains;
Kp_Id; 0.590017
Kp_Iq; 0.590017
Ki_Id; 0.053547
Ki_Iq; 0.053547

Is it noteworthy that LHF is some 40% below the estimated inductance? Additionally, is it noteworthy that the gains generated by CTRL_recalcKpKi and calcPIgains are *very* different?

During normal operation it seems the values generated by calcPIgains are used. (Checked with the CTRL_getKp/Ki functions).

Ok Chris, I think I've started to approach the issue. One strange effect that I've noticed is that with in *increased* USER_IQ_FULL_SCALE_FREQ_Hz the "critical speed" -- the speed where FAST stops reporting the actual motor speed correctly -- *decreases*. As it is now, with a FS_FREQ_Hz of 1500 I can reach speeds of around 1100Hz, which is close enough to my desired top speed for me to be happy.

That said, I am concerned about the inverse behavior; is it possible that at high speeds nearly the entire dynamic range of the IQ24 data type is being used, with only a very small headroom that is gained by decreasing FS_FREQ_Hz? I'm somewhat worried about spurious strange/bad behavior...

//Jonathan

Minjian,

Yes, Rs / Ls gives you a theoretical maximum Hz for your motor. It's good to look at this value to understand if your motor is designed for the speed you are expecting.

The other "sanity check" is Flux (in V/Hz) / 2pi (to convert to Webers) / Ls = Short Circuit current. This gives you a general idea of the current capability of the motor.  So for yours that is an Isc = ~27A

Jonathan,

Going through all of your posts

Rs est current = 10A
Ls est current = -10A

CC: these are way too high. ~10% of the current during full load, and usually just enough to get over the cogging torque during unloaded motor ID.  You stated it takes 5A to start up, so use (5.0) and (-5.0) for motor ID, but I would suggest even lowering these further once ID'd so that if you do an Rs Recal you aren't over heating the wires and getting a bad Rs value. You say later in your post it only draws 2A at unloaded speed, so I would use your Rs value you find with 2A of injection.

Imax = 15A

CC: Why 15A max? Just for some initial safety?  This is limiting the output of your speed PI controller to request only 15A of Iq from the torque controller. This certainly could be limiting your motor during testing. (although if unloaded you only draw 2A this isn't effecting you)

Flux estimation frequency = 40Hz

CC: Increase this to 10%.  Say 150 Hz to get a more consistent Ls value. BTW, your Ls is very small, I assume you are only using Lab 2c to identify correctly?

3. There is no reason to ever have your IQ_V greater than your ADC_V unless you have a large Flux where Flux * Max Hz > ADC_V.  Lower this to at least (68) and I would recommend more like (40), but (50) is ok.

5. You don't need to run FAST at 20 KHz, it's overkill.  But, if you want to use the MIPS, that's fine.  You could run everything just fine at 15 KHz, but I understand if you are using 60 kHz PWM it's easier to just use the (3).

CC: The R/L is not a limitation of FAST, it is a limitation of the motor design. First, I'm not sure you have the correct R and L values for your motor. Please re-ID using my suggestions.  My yes, if your R/L is ~1000, you will NEVER be able to run this motor with the expected voltage bus to 1500 Hz.  You can increase the Bus Voltage (possibly damaging your motor) or use Field Weakening, but R/L is a machine design limitation for motors.

Regarding your last post and the inverse relationship:

CC: I believe you will see more stable results by updating your Voltage filters (HW & SW setting) to use a cross over frequency of your IQ_Hz / 4.  So if you want to use (2000) design the filter for 500 Hz. This is something that we are still investigating as we try higher speed motors, but this /4 has had consistent results. 

But I still think you are hitting the limit of your motor design...

Typically you can get more speed using field weakening, but it depends on the motor. Motors with large flux will allow more field weakening, as you have more starting Bemf to reduce.  Many high speed motors have small flux to begin with, so field weakening may not buy you much.

Isc gives you an idea of the current capability of the motor, and the potential switching current / ripple.  It's not the same as the current required to reach rated torque.

Not sure I understand your last question completely. A current probe is the best tool to use.

You can also buffer the current samples in software and use CCS to plot the values. It does a reasonable job.

Hi Chris:

What 's the relationship between Rs/Ld/Lq and the motor stator winding's resistance R and inductance L. Can we measure the stator's resistance and inductance and then calculate out the Rs and Ld / Lq (For PSMS motor)

Ben

Hi Chris:

    We use three phase current measurement shunt resistance, and then connect together to DC_Bus ground through another shunt resistance (DC bus current shunt resistance?) to measure the DC_Bus current, We need to know the whole electronic power input (DC bus vol * DC bus current?) , and then we can set a threshold to ensure that the power consumption by the motor will not exceed. Currently we use a analog current meter serially connected in the DC bus, for example, if it is display 1A, with DC bus voltage 310V, We will know it consume about 310W power, High the speed, it will be 2A, and consume 620W. Now we want to measure the DC-Bus current (average)  through a  shunt resistance to determine the power consumption. Any suggestion to achieve that?

Going through all of your posts

Rs est current = 10A
Ls est current = -10A

CC: these are way too high. ~10% of the current during full load, and usually just enough to get over the cogging torque during unloaded motor ID.  You stated it takes 5A to start up, so use (5.0) and (-5.0) for motor ID, but I would suggest even lowering these further once ID'd so that if you do an Rs Recal you aren't over heating the wires and getting a bad Rs value. You say later in your post it only draws 2A at unloaded speed, so I would use your Rs value you find with 2A of injection.

I can easily use lower currents when performing an identification; would it be beneficial to use around 3A, and manually help the rotor get started? My naive assumption is that a higher current will increase the accuracy of the idenfication, as there are more bits used in the current input. With an identification current of 5A I'm only effectively using log2(5/ADC_FS_CURR*2^12) = log2(5/330*2^12) ~ 6 bits of resolution... Of course, I really have no idea of how the estimation procedure works and how sensitive it is to error in the current measurement... Any pointers?

Imax = 15A

CC: Why 15A max? Just for some initial safety?  This is limiting the output of your speed PI controller to request only 15A of Iq from the torque controller. This certainly could be limiting your motor during testing. (although if unloaded you only draw 2A this isn't effecting you)

This is a limit solely used for the motor identification, during normal operation a different limit of around 120A is applied. (I'm updating the gUserParams struct before starting the identification/normal operation, seeding new values, and then loading the paramters into the insta-spin subsystem).

Flux estimation frequency = 40Hz

CC: Increase this to 10%.  Say 150 Hz to get a more consistent Ls value. BTW, your Ls is very small, I assume you are only using Lab 2c to identify correctly?

Ok, I'll be sure to stick to around 10% of full speed. And yes, I've based my project on the reference material in lab 2c.

3. There is no reason to ever have your IQ_V greater than your ADC_V unless you have a large Flux where Flux * Max Hz > ADC_V.  Lower this to at least (68) and I would recommend more like (40), but (50) is ok.

Ok!

5. You don't need to run FAST at 20 KHz, it's overkill.  But, if you want to use the MIPS, that's fine.  You could run everything just fine at 15 KHz, but I understand if you are using 60 kHz PWM it's easier to just use the (3).

Well, there's no point in burning cycles just for fun. Do you think that there would be no significant drawback to running FAST at 10kHz for a motor speed of ~1300Hz? If so, I'll just change the appropriate decimator from 1 to 2.

CC: The R/L is not a limitation of FAST, it is a limitation of the motor design. First, I'm not sure you have the correct R and L values for your motor. Please re-ID using my suggestions.  My yes, if your R/L is ~1000, you will NEVER be able to run this motor with the expected voltage bus to 1500 Hz.  You can increase the Bus Voltage (possibly damaging your motor) or use Field Weakening, but R/L is a machine design limitation for motors.

(Disclaimer; I'm relatively new to PMSM motors, so please bear with me). I don't see how R/L, in and of itself, can completely determine the maximum speed of the motor. For example, assume I were to halve the area of the copper conductors in the motor; this would have (nearly) no effect on any parameter other than doubling the series resistance, and thereby halving the R/L cutoff frequency. From a controls perspective obviously this will change the motor behavior (moving the R/L pole to a lower frequency), but I can't see how this will limit the motor speed with some "ideal" commutator/driver. How would the motor be damaged by increasing the bus voltage and increasing the speed? Obviously at some point the motor will (possibly catastrophically) be damaged, but electrically I can't see how this will happen. It's probably worth considering that the "hobby motors" used are probably very far from well designed and thought through, so I doubt that the R/L factor has been chosen to match the motor's maximum speed; if anything I'd guess that both the resistance and inductance are the result of just placing a number of windings around the stator to reduce the series resistance and increasing the magnet thickness to bring the flux to some reasonable value...

Regarding your last post and the inverse relationship:

CC: I believe you will see more stable results by updating your Voltage filters (HW & SW setting) to use a cross over frequency of your IQ_Hz / 4.  So if you want to use (2000) design the filter for 500 Hz. This is something that we are still investigating as we try higher speed motors, but this /4 has had consistent results. 

I'll try this out, thanks!

But I still think you are hitting the limit of your motor design...

Yeah, you'll find no argument from me here, at the moment I'm only concerned with the behavior of FAST, where the speed was not accurately tracked...

//Jonathan

Ben,

"What 's the relationship between Rs/Ld/Lq and the motor stator winding's resistance R and inductance L. Can we measure the stator's resistance and inductance and then calculate out the Rs and Ld / Lq (For PSMS motor)"

Rs = stator resistance

stator inductance average = Ls = Ls-d = Ls-q

Yes, you man measure Rs and Ls by hand (phase to phase) or using the InstaSPIN-FOC Motor ID features (phase to neutral, will be half of phase to phase).

Ben,

Regarding your power measurement, while you can add a return current you should also use be able to use gMotorVars.Is_A, which is defined as (see lab 10a)

// calculate vector Is in amps
gMotorVars.Is_A = _IQsqrt(_IQmpy(gMotorVars.Id_A, gMotorVars.Id_A) + _IQmpy(gMotorVars.Iq_A, gMotorVars.Iq_A));

I think you would need to multiply by Vbus & Vs (which is a per unit scaling of the vector)

// calculate vector Vs in per units
gMotorVars.Vs = _IQsqrt(_IQmpy(gMotorVars.Vd, gMotorVars.Vd) + _IQmpy(gMotorVars.Vq, gMotorVars.Vq));

 gMotorVars.VdcBus_kV = _IQmpy(gAdcData.dcBus,_IQ(USER_IQ_FULL_SCALE_VOLTAGE_V/1000.0));

Chris,

   Thanks a lot! I will check the ID result with the direct measurement. One more question, Is the Rs included the phase current shunt resistance? it is to say that Rs = Rmeasured-phase-to-phase / 2 + Rphase-current-shunt. Will the DC bus return shunt resistance effect the Rs value?

The Motor ID Rs won't exactly match hand measured phase-phase / 2. Remember that for the Motor ID we are injecting some current. Your multimeter current is non-significant. They will be close though.

You don't need to worry about the resistance of the current shunt.

Ben,

Let me correct myself regarding the power measurement.

Here is what we would recommend.

Power in the Field / On the shaft:

Torque (N.m) x Speed (rad/sec) = Power (W)

Alternatively you could try

0.75 x Vbus (V) x (Vd x Id + Vq x Iq) = Power (W)

Chris:

    Thanks for your reply,  I can understand the first equation. But I'd appreciate if you can explain what's the meaning of the second equation more detail. 

0.75 = 3/4 = conversion for RMS line-line

Vd and Vq are in per unit, so they are essentially a % of the Vbus.

Iq and Id are in Amps

So you can think of it as Bus RMS x  % of Bus x Current, and you sum this for Q and D.

Thanks for the pointers Chris. After altering the phase voltage filter to a cutoff frequency of around 450Hz, and (probably more importantly) choosing better filtering capacitors (previously 10V X7R +-20% capacitors, now I'm using 50V X7R +-5% capacitors (the higher voltage specification to reduce the effect of capacitance change vs. DC bias)) everything behaves as expected. It may be worth considering adding a note in the instaspin users guide to select a filtering capacitor with a smaller tolerance than bog-standard decoupling capacitors, though to no small extent do I only have myself to blame for this ;)

REALLY glad to hear that the capacitor issue solved your problems.  Thanks so much for letting us know, it will come up again and again I'm sure!