Meaning of Rotor flux

Mojo,

Rotor flux is the flux linkage between the rotor and the stator, and we give this value in Volts per Hz or Webers (Volt seconds).

The "rotor angle" is actually the angle of the rotor flux.

This is rotor frame referenced, meaning the relative angle is aligned with the Id axis in the d-q frame that rotates with the rotor flux.

Based on this rotor flux angle, an angle is calculated for the vector of the stator flux that you want to create - typically 90 degrees leading based on rotational direction - and defined by an Iq and Id value in the rotating d-q frame.

Hi Mojo,

On a PMSM, the rotor flux is simply a measure of the flux density (i.e., magnet strength) of the magnets attached to the rotor while it is inserted in the stator frame.   I see that you are familiar with the PMSM stator voltage equations for a system where the d-q frame is attached to the rotor.  But at what angle is it attached to the rotor?  In most cases, it is attached at the angle where the north pole of the rotor magnet is pointing to.  This is called the rotor flux axis, and this is what we usually line up the d-axis with.  With InstaSPIN-FOC (as with most FOC algorithms), we are not really concerned with the true rotor flux, since the part of the flux from the magnets that doesn't link to the stator is irrelevant since it doesn't produce any voltage or torque.  When we say "rotor flux", we are really talking about the portion of the rotor flux that jumps the airgap and interacts with the stator.  This is called the rotor flux linkage, which is usually denoted by the symbol l_fd.  In fact, the rotor flux linkage plays a large part in determining the d-axis stator flux, as seen from the equation below:

d-axis stator flux = rotor flux linkage + stator inductance * d-axis stator current.

More importantly, the motor torque can be calculated by simply multiplying the rotor flux linkage times the q-axis stator current times the number of rotor poles/2.  This is how InstaSPIN-FOC calculates torque, and is one of the reasons why we need to accurately determine the amplitude of the rotor flux linkage.

With regard to your second question, please be mindful that the stator current mmf vector is NOT the same as the stator flux vector.  Having said that, the answer to your question is "yes".  Using the equation above, we can calculate the d-axis stator flux.  The q-axis stator flux is defined below:

q-axis stator flux = stator inductance * q-axis stator current.

The MotorID portion of InstaSPIN-FOC measures the stator inductance and the rotor flux linkage.  The FAST portion of InstaSPIN-FOC determines the real-time values of the d and q axis stator currents.  From this you can calculate the d and q axis values of stator flux.  Then you can use rectangular to polar conversion to find the angle of the stator flux w.r.t. the d-axis.

-Dave

...small correction to my last post.

Rotor flux (or flux in general) is a measure of the number of magnetic lines of force being created by the magnetic field in the rotor, and is measured in units of Webers.  "Flux density" is obviously the density of these "lines of force", which is measured in units of flux per area.  1 Weber of flux lines cutting through1 square meter of area creates a flux density of 1 Tesla.    Incidentally, Webers is numerically equal to the back-EMF constant of a PMSM machine in SI units.

Sorry for the confusion,

Dave

Hi Dave,

thanks for the through response.

however, you got me confused. From your first paragraph, I was sure that you're using the air-gap flux linkage reference frame...

then, from the equation -> d-axis stator flux = rotor flux linkage + stator inductance * d-axis stator current

I understand you are talking about the rotor flux linkage reference frame...a little bit confusing....

A phasor diagram here will solve the question, I think. I would appreicate if you can post such a diagram, specifying the angles, vectors etc. this is the most understandable explanation, as I see it...

furthermore, what I fail to understand is :

1. why trying to estimate the rotor flux linkage, since it is constant. you state that you need the ampltude for the torque, but if it's constant...

2. you stated that instaSPIN-FOC calculates the torque as : rotor_flux*Iq.  this, however, is a very very short expression of the whole... in case of salient pole, or synchronous motor with dampers..

your comments are mostly appreciated,

thanks

Hi,

I would like to implement a BEMF feedforward compensation. That is:

Uff_d = -w*Psi_q

Uff_q = w*Psi_d

where the stator flux linkage is of course:

Psi_q = Lq*Iq => [H]*[A]

Psi_d = Psi_rotor+Ld*Id => [Weber]+[H]*[A]

w=rotor electrical frequency [rad/sec]

My questions are:

1. Which variables / terms in the Motorware software do you suggest on using for calculation of the different terms of the stator flux linkage ? I'm a little bit lost with all the units (p.u,volt/Hz etc).

2. In order to combine into the controller, some sort of per-unit transformation is needed (after calculating Uff in SI unit, I need to convert to p.u). How do you suggest on doing that ? (I thought just to use Uff/MAX_VOLTAGE, as set in user.h)

thanks a lot

Hi,

You can use the following global variables:

_iq gLd_H;
_iq gLq_H;
_iq gId_A;
_iq gIq_A;
_iq gPsi_rotor_VpHz;
_iq gPsi_d_VpHz;
_iq gPsi_q_VpHz;
_iq gUff_d_pu;
_iq gUff_q_pu;

And then, run this code:

  gLd_H = _IQ(EST_getLs_d_H(obj->estHandle));
  gLq_H = _IQ(EST_getLs_q_H(obj->estHandle));
  gPsi_rotor_VpHz = _IQ(EST_getFlux_VpHz(obj->estHandle));

  gId_A = _IQmpy(CTRL_getId_in_pu(handle),_IQ(USER_IQ_FULL_SCALE_CURRENT_A));
  gIq_A = _IQmpy(CTRL_getIq_in_pu(handle),_IQ(USER_IQ_FULL_SCALE_CURRENT_A));

  gPsi_d_VpHz = gPsi_rotor_VpHz + _IQmpy(_IQmpy(gLd_H,gId_A),_IQ(2*MATH_PI));
  gPsi_q_VpHz = _IQmpy(_IQmpy(gLq_H,gIq_A),_IQ(2*MATH_PI));

  gUff_d_pu = _IQmpy(gPsi_q_VpHz,_IQmpy(EST_getFe_pu(obj->estHandle),_IQ(USER_IQ_FULL_SCALE_FREQ_Hz/USER_IQ_FULL_SCALE_VOLTAGE_V)));
  gUff_q_pu = _IQmpy(gPsi_d_VpHz,_IQmpy(EST_getFe_pu(obj->estHandle),_IQ(USER_IQ_FULL_SCALE_FREQ_Hz/USER_IQ_FULL_SCALE_VOLTAGE_V)));

A couple of comments on this code:

1. All of it is done in V/Hz to avoid saturation of an IQ24 on the last scale factor of: _IQ(USER_IQ_FULL_SCALE_FREQ_Hz/USER_IQ_FULL_SCALE_VOLTAGE_V). If we do everything in Weber, this calculation would have been needed: _IQ(USER_IQ_FULL_SCALE_FREQ_Hz*2*MATH_PI/USER_IQ_FULL_SCALE_VOLTAGE_V), which for typical values of USER_IQ_FULL_SCALE_FREQ_Hz = 800 and USER_IQ_FULL_SCALE_VOLTAGE_V = 24 this saturates the IQ24 maximum value of 127.99 since the operation results in 209.44, so it was more convenient to do using V/Hz.
2. These two operations gLd_H = _IQ(EST_getLs_d_H(obj->estHandle)); and gLq_H = _IQ(EST_getLs_q_H(obj->estHandle)); doesn't have to be run all the time, actually you can just run them once the inductance have been loaded, and they won't change, to save some bandwidth.
3. This operation: gPsi_rotor_VpHz = _IQ(EST_getFlux_VpHz(obj->estHandle)); has to be run continuously since the rotor flux can change during transients, etc. Although be careful if this is run at the ISR rate, since we run some floating point calculations inside of this function call, so it might impact your ability to run at very high ISR rated. One solution is to have this function call in a background loop, so executing as frequent as possible, without being inside an ISR.
4. The outputs gUff_d_pu and gUff_q_pu are already in per units, and can be added directly to the output of the current controllers. I would recommend some saturation limits after you perform the addition of the current controller output with these new feedforward voltages, just to make sure the overall output isn't overflowing or something.

I hope this helps!

-Jorge

Hi Jorge,

Thanks a lot for the code snippet !

One question please - why do you multiply by 2*PI:

_IQmpy(_IQmpy(gLd_H,gId_A),_IQ(2*MATH_PI))

thanks again, It very helpful

Hi,

I multiply to get the flux in V/Hz. So in V/Hz:

  gPsi_rotor_VpHz = _IQ(EST_getFlux_VpHz(obj->estHandle));

  gPsi_d_VpHz = gPsi_rotor_VpHz + _IQmpy(_IQmpy(gLd_H,gId_A),_IQ(2*MATH_PI));
  gPsi_q_VpHz = _IQmpy(_IQmpy(gLq_H,gIq_A),_IQ(2*MATH_PI));

In Wb:

  gPsi_rotor_Wb = _IQ(EST_getFlux_Wb(obj->estHandle));

  gPsi_d_Wb = gPsi_rotor_Wb + _IQmpy(gLd_H,gId_A);
  gPsi_q_Wb = _IQmpy(gLq_H,gIq_A);

-Jorge

wB * 2pi = V/Hz

Hi Jorge,

2 comments:

1. Since Uff_d = -w*Psi_q, there should be a minus sign (-) when calculating Uff_d - i.e

-(_IQmpy(gPsi_q_VpHz,_IQmpy(EST_

getFe_pu(obj->estHandle),_IQ(USER_IQ_FULL_SCALE_FREQ_Hz/USER_IQ_FULL_SCALE_VOLTAGE_V))));

2. If using floating point builds, then the flux value should be obtained using the union interface:

union
       {
         int32_t   long_value;
         float_t float_value;
       } interface;
     interface.long_value = EST_getFlux_VpHz(obj->estHandle);
     gPsi_rotor_VpHz = _IQ(interface.float_value);

correct me if I' wrong...

Yes, I agree on the negative, although you can keep the operation positive, and subtract it from the output of the current controller, your choice.

Yes, you are also correct on the floating point build using a union.

-Jorge

Hi Jorge,

So as you said, the function EST_getFlux_VpHz takes forever to run (40us to be more accurate...)

Since I would like to get the flux in the ISR, I tried using EST_getFlux_pu as following (taken from TI code in est.h):

#define VarShift(var,nshift) (((nshift) < 0) ? ((var)>>(-(nshift))) : ((var)<<(nshift)))

_iq Flux_Wb;
_iq Flux_pu = EST_getFlux_pu(obj->estHandle);
_iq FullScaleFlux = _IQ(USER_IQ_FULL_SCALE_VOLTAGE_V/USER_EST_FREQ_Hz);
uint_least8_t Flux_qFmt = EST_getFlux_qFmt(obj->estHandle);
_iq scale_factor = VarShift(FullScaleFlux, Flux_qFmt - 30);

Flux_Wb = _IQmpy(Flux_pu, scale_factor);

gPsi_rotor_VpHz = _IQmpy(Flux_Wb, _IQ(6.28)); // 6.28 is 2*pi

This code indeed runs faster (less than 1us).

However, I don't get same value when calculated as the above code (I got 0.035 V/Hz) and when using EST_getFlux_VpHz (I get 0.019 V/Hz, which is correct, and this is also the value when running the Motor ID)

Is the above method correct ?

why is there a difference ?

Thanks a lot

Mojo,

We have just confirmed this is a bug with getFlux_pu() and EST_getFlux_qFmt()

This will return the wrong value through MotorWare _11 at a minimum (likely _12 as well).

We will see if this is something we can patch outside the ROM for future release. For now the only proper way to get Flux is to request it in your non time critical code with the EST_getFlux_VpHz.

Hey Dave, 

firstly thank you so much on that great explanation on what rotor flux and rotor flux linkage is, that clarified a lot. I would like to know if you could also explain what is meant by weakening the rotor flux linkages?

Reagrds,

Greg. 

Hi Greg,

Unfortunately I can't see my explanation you are referring to, so I don't know what I may have already said related to this topic.  But no matter...I'm glad you found it to be helpful.

As the rotor spins inside the set of stator coils, it induces a back-EMF voltage resulting from d-flux/dt.  This means that as the rotor spins faster relative to the stationary stator coils, this back-EMF voltage increases.  You soon reach a point near the full-speed rating of the motor where the back-EMF voltage is so high, it inhibits the ability of the applied voltage to produce current, and the motor cannot go any faster.

At this point, you have two choices:  1)  Increase the applied voltage, or 2) Decrease the back-EMF voltage.  In many cases, increasing the applied voltage is just not economically practical.  So most designers choose to reduce the back-EMF voltage.  This is done by passing a current through the stator coils at just the right spatial angle so as to create a counter-flux in the stator coil which opposes the original flux linked from the rotor magnet.  Since the stator coil's net flux linkage is reduced, the d-flux/dt is also reduced for a given speed.  It turns out that in a field-oriented system, the optimum spatial angle to apply this stator current is along the axis which the rotor flux is currently pointing.  In other words, along the d-axis.  So, in order to oppose the rotor flux, we must supply a negative current on the d-axis.

One very common misconception about field weakening (at least with permanent magnet machines) is that fleld weakening reduces the rotor flux.  this is not true.  The rotor flux is established by the field strength of the rotor magnets, and is "permanent".  What we are doing is reducing the flux that links into the stator coils.  Therefore, as a result of field weakening, you motor can achieve speeds that are higher than the rated speed of the motor, but at a cost of reduced efficiency due to the extra stator current required to do this.

Best Regards,

Dave