Why motor speed estimate is wrong /how is motor speed iscalculated in/by FAST…we get wrong results?

Kusti,

Another customer sent me their motor yesterday that is used for a similar application and I noticed something.  The motor I have has a relatively large Rs (1.0 ohm) and presumably a small Ls (I measured 18uH the first run through with 2c), however this is Ls is invalid.  I've only seen this happen on two other motors, but the during EST_State RoverL, even with 2c (for high speed, low Ls motors) the Lhf and RoverL get so large that they roll over negative.

Please run motor Id again and look at the controller_obj (with 6x; with 2x look at ctrl.) for variables Rhf, Lhf, and RoverL right after EST_State Rs starts.

So, I believe the first thing to solve is to get a valid Ls. We need to make a SW update for this type of motor, but in the meantime I think we can make some educated guesses.

In the case of my motor the first thing I did was to set a first reasonable Ls just based on

Rs / Ls < CTRL_FREQ

1.0 ohm / 15 KHz < Ls, so Ls > 66 uH

Setting Ls from 18uH to 70uH helped some, but it still isn't correct IMO.

For this motor Flux = 0.024 V/H = 0.0038 Wb

It is 6A continuous, so I suspect it should have an Isc of 12A+, that means

Flux_Wb / Ls > 12A, so Ls < 318uH

I think my Ls should fall somewhere in the 100-250uH range, so I can do some testing with values in this range

Kustaa Nyholm said:

I thought the 'commutation' ie inverse park is based on the rotor angle and thus I would have expected that this needs to be correct for the motor to run but now it seems like there is discrepancy somewhere...

With full load you need the angle to be relatively precise as the Torque you produce will be weighted by sin (theta), where theta is the angle between the stator and flux vectors, which you want to keep at 90 degrees for non-salient synchronous machines (this is accomplished by regulating Id = 0).

At no load the angle can have a large error and still produce enough torque to make the rotor rotate...it's not what you want, but just because the motor spins doesn't mean that the angle is being detected correctly.  And in the case of FAST that's usually because the motor parameters are wrong or have changed, or because the measurements are corrupted.

Just when you wrote I had completed re-run of lab2b (I have now done a complete re-install /upgrade of CCS 6 to remove any doubt of old compilers etc).

Below is what I got, they look reasonable to me, line to line measurements for this motor using an inductance meter show 111-119 uH so ~ 60 uH per coil which mathce what the manufacturer of the motor specifies and line to line resistance is 1.88-1.97 Ohms i.e. 0.95 Ohm / coil, again matching what the manufacturer specifies and what I got from lab2b (below).

Should I try now lab2c as you suggested?

Is sending you a motor to test an option?

br Kusti

Kusti,

Also, I assume you are using the default value of

#define USER_R_OVER_L_EST_FREQ_Hz (300.0)

In one case, I could only produce this negative Lhf with a setting of (100.0), and changing this to (300.0) have proper readings.

I have not tried (300.0) on the dental motor I have....will do so later this week....interested to see how your motor IDs by varying this value from 100, 200, and 300 using proj_lab02c.

Ok, this is lab2c and the values you asked for:

and the results of the motor ID process:

Please expand your Expressions to show the

controller_obj

scroll down to

Rhf
Lhf
RoverL

I'd like to see those after running 02b and 02c with

USER_R_OVER_L_EST_FREQ_Hz set to (100), (200), and (300)

as well as the final ID'd Ls value.

so 6 different screen shots (or put the values in a spreadsheet)

Yes, I'm using the default value

#define USER_R_OVER_L_EST_FREQ_Hz (300.0)

A comment and an observation:

the very first screen shot was done with the motor attached to the dyno, but no load, with lab2b.

Trying to run lab2c with dyno fails to spin the motor properly so those screen shots are with the motor spinning free air.

Ok I will not proceed to make the six screen shots you asked for.

br Kusti

Of course I meant to say I will *now* proceed to make the requested measurements ;)

Here are the results:

lab2b/100

lab2b/200

lab2b/300

lab2c/100

lab2c/200

lab2c/300

to me 2b with default 300 frequency looks most reliable and the motor also sounds runs and sounds smoothes through out the test where as 2c makes funny noises and sounds wobbly at times FWIW.

br Kusti

Kusti,

What PWM frequency are you running with DRV8301 EVM?

I would recommend you try to run at 15 KHz (set other ticks to (1) and then SPEED/TRAJ to (15)) and see if the values improve for 2b and 2c with (200) and (300)....you can stop using (100) that obviously isn't working.

My guess is that somewhere around 80uH is probably the Ls you want to use...The values <50uH are going to give you an User Check Error because R / L will be > CTRL freq.

These are strange motors to have such a large Rs value for such a small Ls...I wonder why they are designed that way?  I think you would get better control and use less power if Rs was lower.

I'm running at 

#define USER_PWM_FREQ_kHz                (50) 

as I get the R/L error with smaller values IIRC, but maybe my L was different back when I changed this.

Ok, I'll experiment more tomorrow when I'm back at lab.

I believe the motor characteristics come from the physical factors, these are small (D=20 mm L=40mm)

the rotor is about 10 mm, they are packed to the rim so I expect they can't fit more/thicker copper in there,

If you want we are more than happy send you one for experimenting.

br Kusti

Good Morning,

so I set:

#define USER_NUM_PWM_TICKS_PER_ISR_TICK        (1)

is that what you had in mind?

I re-run labs 2b and 2c (at 300 Hz)

lab2b:

lab2c:

:

so I don't see that it made a difference.

Anyway, tried the lab5b and the speed measurement is still of by 10%, when I set ref to 4 krpm

the actual rpm as show by the dyno is 3.6 and the performance was worse, I can only get about 7 mNm torque where as with 50 kHz I was able to get into the ballpark of 20 mNm.

To me going down in PWM is counter intuitive and agains what the code says for low inductance motors….

Anyway as I see it our first and foremost problem is that the speed measurement is wrong/faulty. The PI-controllers are quite happy and don't put out more torque even though loading the motor drops the actual rpm. The error is rather consistent 10% at 500 rpm and 5000 rpm.

So how do I debug this?

br Kusti

Yes, agree, the 15 KHz doesn't seem to have made much difference.

It's clear that you should use PWM and ticks of

(45), (3), (1), (1), (1), (15), (15)

or with the F2806x you could try

(60) ,(3), (2), (1), (1), (10), (10)

Kustaa Nyholm said:

Anyway, tried the lab5b and the speed measurement is still of by 10%, when I set ref to 4 krpm

The speed controller is NOT automatically tuned. Please explain how you tuned the system?

Is there a speed error between the gMotorVars  Speed Ref and Speed or just with the Dyno?

Which Ls value are you using?

Kustaa Nyholm said:

To me going down in PWM is counter intuitive and agains what the code says for low inductance motors….

the 15 KHz suggestion was just for motor ID. The DRV8301 EVM has some noisy switching so sometimes it helps for ID to not switch as fast.  For on-line control, I agree, you need to PWM faster.

"The speed controller is NOT automatically tuned. Please explain how you tuned the system?"

I didn't, must have slept through that lab session ;) !

"Is there a speed error between the gMotorVars  Speed Ref and Speed or just with the Dyno?"

Speed ref and speed (if I got you correctly) agree but dyno disagree with them.

My concern is not so much if it is 10% off or not but the fact that when I load the motor the

the measured rpm indicates that the speed is ok (more or less tracks speed ref) and thus

the PI controllers are happy and don't put out enough torque and the real rpm drops.

Which Ls value are you using?

I was usin 72 uH for Ls because I had to up it from the ID'd 69 uH cause I was trying to run with 15 kHz PWM.

Kustaa Nyholm said:

To me going down in PWM is counter intuitive and agains what the code says for low inductance motors….

the 15 KHz suggestion was just for motor ID. The DRV8301 EVM has some noisy switching so sometimes it helps for ID to not switch as fast.  For on-line control, I agree, you need to PWM faster.

Kustaa Nyholm said:

"Is there a speed error between the gMotorVars  Speed Ref and Speed or just with the Dyno?"

Speed ref and speed (if I got you correctly) agree but dyno disagree with them.

My concern is not so much if it is 10% off or not but the fact that when I load the motor the

the measured rpm indicates that the speed is ok (more or less tracks speed ref) and thus

the PI controllers are happy and don't put out enough torque and the real rpm drops.

Correct, if the Speed Est and Speed Ref are the same, then the controller is doing its job.  If the Speed Est disagrees with the dyno - and you trust your dyno - then the motor parameters being used are incorrect or have drifted.  I think it points to the fact that Ls is wrong.  Why don't you use the dyno to try to tune your Ls value?  Try increasing and see if the Speed Est changes

Here is the motor very similar to yours.

I upped the Ls to 100uH to see if that helped things...it seems to, but it's still not exactly correct.

You can see how low I adjusted the speed loop gains, the "rule of thumb" we use for default speed gains is much to high for large R over L (small time constant) motors.

This is 45 KHz

Thanks, I'll take shot at this the first opportunity, the dyno is busy for a few days in an other project.

br Kusti

Kustaa,

I've run some more tests with BOOSTXL-DRV8301 @ 18V.

I still can't get valid Ls Identified for these motors. I can confirm

- 15 KHz heats the motors, use 45 KHz. 60 KHz gave invalid results (I think due to the state machine timing when using the ISR_TICKS_PER_CTRL_TICK which is necessary with the 27F @ 60 MHz)

- RoverLof (100) never works. (200) works the best

- Even with this I ID Ls of about 40uH

- 40 uH is not valid when using a 15 KHz control rate as 15 KHz > 1.0 ohm / 40uH, so I had to raise to 73 uH

- when running with 73uH things run REALLY well in torque and speed mode at high speed.  Flux is stable and torque is right where it should be

- at low speeds the speed controller is really giving me problems, it doesn't command torque fast enough so stalls occur.

- low speeds aren't even possible with torque mode....lowest I could get was about 4 kRPM continuous with a load

- one thing I notice is that just a TINY amount of Iq_Ref makes the motor take off and reach max speed. I'm talking 0.1A.  And it has so much inertia that even if I command 0A while it's running it won't turn off with no-load.  It just spins and spins.  But barely touch it and it does stop.

I'm curious about the solution today...does it control speed, or just torque?  How does the user command the speed or torque they want?  If speed, what is the lowest you can run today?

Thanks for running all those test.

Your description of your experience (and motor!) sound almost identical to mine!

Today I was able to run 1000 rpm at 16 nNm torque which is about 80% of  the torque that the manufactures specifies for this motor.  Loading it more and the real rpm at dyno starts to go down though the InstaSpeed measured rpm stays  at set ref.

Lowest I was able to run reliably was 500 rpm. 

You experience in torque mode is also what I get.

Today  I hooked the motor manufacturers electronics to the motor and run it with the dyno. I goes down to 100 rmp and still torgues 8 mNm after which it seems that some software limit kicks in, I need to confirm the figures tomorrow and check if there is some limit I can change as this is supposed to do 20 mNm. And it really runs nicely at 100 rpm.

br Kusti

Kustaa Nyholm said:

Loading it more and the real rpm at dyno starts to go down though the InstaSpeed measured rpm stays  at set ref.

this is something I'm not seeing at all.  please post your user.h so we can double check.

Kustaa Nyholm said:

Lowest I was able to run reliably was 500 rpm. 

This is with proj_lab05b and speed gains tuned to what?

I think if you use InstaSPIN-MOTION and the SpinTAC controller you will see a big improvement here.  I haven't had a chance to test.

Kustaa Nyholm said:

Today  I hooked the motor manufacturers electronics to the motor and run it with the dyno. I goes down to 100 rmp and still torgues 8 mNm after which it seems that some software limit kicks in, I need to confirm the figures tomorrow and check if there is some limit I can change as this is supposed to do 20 mNm. And it really runs nicely at 100 rpm.

What is the command? Are you requesting a specific speed or just a torque?  How does the user send this command to the inverter?

this is something I'm not seeing at all.  please post your user.h so we can double check.

Ok, will do tomorrow, don't have the file at home.

This is with proj_lab05b and speed gains tuned to what?

Tried different values, will post some samples from the office tomorrow.

I think if you use InstaSPIN-MOTION and the SpinTAC controller you will see a big improvement here.  I haven't had a chance to test.

Hope to hear from your experiments with your current motor and the one we will send you. Shouldn't I get the speed controller tuned up before I proceed to motion and tac?

What is the command? Are you requesting a specific speed or just a torque?  How does the user send this command to the inverter?

We set  the desired rpm via a potentiometer and then just brake it with the dyno. In the actual application the user selects a speed range and controls the speed ref voltage via a foot control/pedal (instead of a pot).

Ok redid a lot of thing this morning to confirm a thing or two.

Here is what I found.

1) Our dyna is accurate but the contra angle hand piece that connects the motor to the dyno which was supposed to have a gearing ratio of 1:1 actually has about 1 : 0.9 ratio!! How about  that. Now I have a direct/straight hand piece and the dyno and InstaSpin agree within 0.5% of rpm

2) In the process of tracking down the nasty compiler bug I had restored all motorware code and that had disable my online Rs calculation and the motor heating up made everything very difficult. Now I've put back the (InstaSpin User Guide p 438/439) and the performance is much more consistent.

3) I went back to the motor manufacturers electronics and redid measurements this is what I get:

100 rpm 30 mNm

1000 rpm 25 mNm

5000 rpm 25 mNm

this electronics commutates at 32 VDC. The motor spec is 8.18 mNm/A and max continuous current 2.5 A, 10 sec for 4.2 A which says to me max 34 mNm and I think all this is in harmony and internally consistent.

4) I went back to my lab5b and user.h (attached) and this what I now get:

1000 rpm 23 mNm  (I find this pretty much inline with what to expect at 24 VDC and 86% max modulation)

500 rpm 19 mNm

400 rpm 15 mNm

5) By disabling force angle I can make the motor rotate somewhat decently at 300 rpm even 100 rpm but erratically but no torque to speak of. The lowest rpm I can load the motor reliably is 400 rpm.

6) I forgot to mention we changed the current measurement scaling so now I have

#define USER_ADC_FULL_SCALE_CURRENT_A        (9.9)  // 33.0 boostxldrv8301_revB current scaling

Ok that just about covers it for today.

Ah, oh yes, 

7) I experimented with L=100 uH and 200 uH and also various PI speed factors but nothing seemed to make much difference for better or worse until they created serious problems. I think the online Rs calibration was the key to make this work as well as it does atm.

So now really the main issue is the original issue ie the low speed performance.

8) I think we will try to increase the ADC resolution for voltage measurements next. Any thoughts about how to best go about this are appreciated. We found some nice 14 bit SPI interfaced ADCs but the SPI on the boost board is in use and maybe not suitable for the ADC we had in mind.

Can you confirm that the ADC happens in a round robin fashion at PWM frequency ie 45 kHz ie the same channel is sampled every 7/45000 ~155 uSec ? That's how I interpreted the code and cpu data sheet.

Have a nice weekend.

br Kusti

1715.user.h

Are you able to design your own motor, or just modify this one slightly?

There is no reason for the speed, torque and current you need that this motor has such a high Rs and low Ls.  This motor is designed to have stability at a ridiculously high open loop frequency of 16 kHz (Rs / Ls).

An Isc of 2x rated, so say 8A, with your 0.025 V/Hz, would say Ls = 500uH, then R/L = 2 KHz, which would be very reasonable.

Your current ripple would go WAY down, your motor wouldn't heat up as much, etc.

You should be able to try this just by putting 0.5mH inductors on our phases.

We are looking at this more and the over riding issue is the current sampling. This is what is messing up the ID and then even the control.  Because the currents have such high switching current (due to small Ls) we aren't getting good readings when we sample (which yes is at Timer = 0 which is the center of the PWM frequency when the lower legs are in the middle of their on cycle, and we sample sequentially all of the channels every PWM cycle, 45 KHz in your case....but because you are using a tick of (3) we are only interrupting the control system and using the ADC samples every third time, so every 15 KHz effective).

How can we get better samples?

- have a motor with lower Isc. You only need this about 2x your rated. Yours is about 16x your rated.  You can't lower your flux (you need it for torque) so you should increase your Ls by a factor of 8x.  This could be in the motor or on the inverter hardware.

- you could use in-line phase current sensors (LEM, hall). This allows you to get better samples, and you can even do some over sampling / averaging to get better values. You don't have to worry about low side sampling right after a switching event which is what is corrupting our solution.

FYI, regarding your user.h:

since you changed your ADC_C to (9.9) you should change your IQ_C to (5.0)

Thanks,

I'm a bit tired atm, been a long week, so I will read you response later with fresher brain, just a few quick comments.

This motor and half a dozen more like it are given, not a chance changing them, the motor manufactures have their reason for designing them as they are and are not giving out those reason. The motors have very strong brands and sales channel, often the motor is 'sold' to the customer way before we come into play, so we just have to cope with them. At the moment we can drive some, maybe most with our current control system, but this particular motor is a beast, unfortunately it is one of the most prestigious ones...

The original electronics has inductors in series and we did try that, but that was before we found out about the compiler issue so I guess we need to re-visit this. x8 you say, ie about 0.5 mH in series on each phase, right?

Ack the IQ_C = 5, I did wonder about that.

Thanks and have a nice weekend.

br Kusti

Hi,

on second reading I'm not sure what IQ_C refers to, can you elaborate please?

br Kusti

Hi,

we just tried the motor with 500 uH 0.3 Ohm inductances in series with motor windings.

The motor was now identified as :

#define USER_MOTOR_Rs                   (1.208895)

#define USER_MOTOR_Ls_d                 (0.0005172755)

#define USER_MOTOR_Ls_q                 (USER_MOTOR_Ls_d)

#define USER_MOTOR_RATED_FLUX           (0.02524986)

I think the identification (lab2b at 300 Hz) worked better because at the ramp up phase the motor actually seemed to obey the control, but at lab5b the performance did not change, 1000 rpm / 24 mNm, 300 rmp 17 mNm, can't get the motor to run properly below 300 rpm.

br Kusti

Kustaa Nyholm said:

on second reading I'm not sure what IQ_C refers to, can you elaborate please?

USER_IQ_FULL_SCALE_CURRENT_A

You chanced your USER_ADC_FULL_SCALE_CURRENT_A so change

USER_IQ_FULL_SCALE_CURRENT_A >= 0.5 * USER_ADC_FULL_SCALE_CURRENT_A

I tried myself and haven't been able to ID with 2b or 2c...hmmmmm.

As mentiond I'll do some work on this Thursday morning with another expert.

Kustaa Nyholm said:

we just tried the motor with 500 uH 0.3 Ohm inductances in series with motor windings.

The motor was now identified as :

#define USER_MOTOR_Rs                   (1.208895)

#define USER_MOTOR_Ls_d                 (0.0005172755)

#define USER_MOTOR_Ls_q                 (USER_MOTOR_Ls_d)

#define USER_MOTOR_RATED_FLUX           (0.02524986)

Kusti (and others who are following this original thread)

I made a mistake on where to place the inductors.

When done this way the  USER_MOTOR_Ls_d of the motor should be the original Ls and NOT that of the external inductor . In fact, it will be much easier to identify consistently now as the current ripple will be quite reduced.

if you can use 50uH+ you will see really nice results we think.

Here is 4333 Hz motor with 30 KHz PWM

(recall, control theory states that we need to run control loops at least x7 the max frequency, so we are 30 KHz current controller as well)

additional information for posterity

when you use this type of circuit you should still ID only the inductance of the motor, which is critical for FAST to estimate correctly (you don't want the extra inductance in the estimator), so for example you may have:

#define USER_MOTOR_Ls_d                 (0.000009)

However, the extra inductance DOES need to be taken into account for the current control Kp gain calculations! The Kp calculation is done by the equation

      _iq Kp = _IQ(0.25*USER_MOTOR_Ls_d*USER_IQ_FULL_SCALE_CURRENT_A/(USER_CTRL_PERIOD_sec*USER_IQ_FULL_SCALE_VOLTAGE_V));

so to update this for the new combined inductance you could do something like this

in user.h

#define USER_MOTOR_Ls_sf ((Lext + USER_MOTOR_Ls_d)/USER_MOTOR_Ls_d)

gMotorVars.Kp_Idq = CTRL_getKp(ctrlHandle,CTRL_Type_PID_Id);
Kp = _IQ(gMotorVars.Kp_Idq*USER_MOTOR_Ls_sf)

      // set the controller proportional gains
      CTRL_setKp(handle,CTRL_Type_PID_Id,Kp);
      CTRL_setKp(handle,CTRL_Type_PID_Iq,Kp);

And if you want to know how to choose Lext, one way would be to look at the short circuit current and design Isc = 2 * Irated (many of these motors have Isc >>> Irated)

As an example for a motor with rated current for rated load of 3A, Ls = 11.65uH, and 0.0018 V/Hz

Lext_ideal = flux/(2*Irated) - Ls = 0.2958e-3/(2*3) - 11.65e-6 = 37.65 uH

here Flux is in Wb = V/Hz divided by 2pi

So adding 37 uH of external Ls would still give you full performance. Any more could help the current ripple but will slowly start to degrade your maximum torque capability.

Ls_sf = ~4.5, meaning your default Kp gain will be 4.5 times larger.

Hi Chris,

thanks for that, I will get into this in about two weeks when I'm back from holidays.

br Kusti

Hi Chris,

back by the lathe side.

I think we understand what you wrote but at the moment the main issue is we are pursuing is the low RPM performance and we are experimenting with the InstaSpeed BLDC and modifying the hardware to get better back EMF resolution. So this raises the question: if we were to try the FAST solution with the additional inductance and sw mods you described is it likely that we can get down to 60-100 rpm range with our motor? Did you test this with our motor? 

If it is not likely then we will continue with the BLDC solution to see if that leads us anywhere...

br Kusti

Kusti,

It will help with getting slightly better current signals, but I am not confident that it will be good enough for the performance you are looking for at low speeds.  The main factor in improving low speed performance would be larger Bemf measurements relative to the scale.  Gaining up the Flux measurement when at low speeds would probably help the most for FAST and your Bemf BLDC application.