Load problem : speed loop in saturation

let me first comment on your user.h

#define USER_ADC_FULL_SCALE_CURRENT_A         (250.0)

you are measuring +/- 125A

your Vbus is 15V or 24V?  But you copied the circuits of the DRV8312 EVM and are reading 0 to 66.32 V?

#define USER_NUM_PWM_TICKS_PER_ISR_TICK        (3)

this is dividing your 15 KHz clock by 3, setting your inner control loops at 5 KHz and your outer to 5/15.  You don't need to do that. Change this to (1)

you probably need to increase this value for Id, although it will be hard to ID this motor with the current release:

#define USER_IDRATED_DELTA                  (0.00002)

you can leave this at (100)

#define USER_R_OVER_L_EST_FREQ_Hz (150)

I would say that your motor parameters are the main problem since ID failed. Even if you are using an encoder the Rs and Ls are used for setting the current control gains.  Also, (48) lines isn't valid for an encoder lines, it should be much higher.

#define USER_MOTOR_TYPE                 MOTOR_Type_Induction
#define USER_MOTOR_NUM_POLE_PAIRS       (2)
#define USER_MOTOR_Rr                   (USER_MOTOR_Rs*0.7)        //by guess, motor ID failed
#define USER_MOTOR_Rs                   (0.027)                    //by motor ID
#define USER_MOTOR_Ls_d                 (USER_MOTOR_Rs/2.0/169.0)  //by guess, motor ID failed
#define USER_MOTOR_Ls_q                 (USER_MOTOR_Ls_d)     //by guess, motor ID failed
#define USER_MOTOR_RATED_FLUX           (0.8165*15.0/115.0)
#define USER_MOTOR_MAGNETIZING_CURRENT  (13.25)        //by motor ID
#define USER_MOTOR_RES_EST_CURRENT      (8.0)
#define USER_MOTOR_IND_EST_CURRENT      (NULL)
#define USER_MOTOR_MAX_CURRENT          (43.0)
#define USER_MOTOR_FLUX_EST_FREQ_Hz     (5.0)
#define USER_MOTOR_ENCODER_LINES        (48.0)

Hello Chris,

Thank you for your help!

These are some reply to your doubts：

your Vbus is 15V or 24V?  But you copied the circuits of the DRV8312 EVM and are reading 0 to 66.32 V?

Our Vbus is 24V， but our critical hardware of resistor divider and capacity filter are the same as DRV8301 EVM. So we keep the USER_ADC_FULL_SCALE_VOLTAGE_V  66.32V.

 Also, (48) lines isn't valid for an encoder lines, it should be much higher.

The sensor datasheet of this ACIM shows "sensor bering 48 impulses ".

Then, we are sorry to tell that we failed to get  standard parameters from ABM, maybe for technical confidentiality reasons or something else.

As you recommanded, we adjusted these value:

#define USER_ADC_FULL_SCALE_CURRENT_A         (250.0)

#define USER_NUM_PWM_TICKS_PER_ISR_TICK      (1)

#define USER_R_OVER_L_EST_FREQ_Hz                   (100)

#define USER_MOTOR_RATED_FLUX                          (0.8165*15.0/115)

And we worked for a few days and went back to lab02b to remeasure USER_MOTOR values. Here is a test recoad:

As we can see, the values of Rr,Rs and I_MAGNETIZING have very small fluctuations. But the Ls is volatile and may have wrong tset results.

In another way, we use a handheld LCR meter to measure the inductance between U and W, U and V, V and W, in 10Khz. So we wrok out the Ls in this way.

Is this way right...?

We will continue the load test as soon as we get the exact USER_MOTOR values.

Best regards.

Brant Zheng

Hello Chris,

Our  user.h and parameters datasheet.

5344.user.h

4606.Anh_E20363_1.pdf

I'm sorry that we made a mistake that we forgot to change the Rated_FLUX (0.08165*15/115) to Rated_FLUX (0.08165*15/66) when running lab02b. When Rated_FLUX (0.08165*15/66) , we got the ID result of magnetizing current, it's 30.5A, do you think it is a proper value?

As you recommanded, we calculated the Rr, Rs, Ls from reactance(X) value and filled them in user.h. And we have a puzzle that Rated_FLUX=(0.8165*15/66)=0.1856V/Hz in user.h but Rated_FLUX=0.02 calculated from reactance(X) value. The two calculated values differ greatly. So which one is right? And could you tell us is there anything else wrong in user.h? Thank you very much!

add:

The max current of this motor is 43A. So the peak current is 43*√(2)=60.8A and we choose ACS759-100 as the isolated current sampling chip with a sensitivity sens of 13.2mV/A and a sampled current range of ±100A.

And we adjusted the resistance divider to increse the voltage resolution. Now USER_ADC_FULL_SCALE_VOLTAGE_V       (31.2) 

Best regards!

Brant Zheng

Brant,

In addition to tuning the current loops, the motor parameters are used to setup the slip compensation for the encoder.  If your motor parameters were not 100% correct your issue makes a lot of sense.  As you increase load on the system the slip is going to become larger and eventually the angle provided to the FOC will become increasingly incorrect and it will lose the ability to control the motor.

Hello Chris and Adam, 

Thank you for supporting us from we using the EVM board to now making the load test as the last step of our project.

To get 100% correct motor parameters, we asked our motor applier for the exact  reactance values to perfect our user.h.

But the fact is cruel.  It can not even bear a slight load in lab13e but run normally with no load. With load incresing, it stop, spin and lose control.

As Chris recommanded, we ran the lab05b with no load. It could not start normally and vibrated violently. It behaved worse than using the parameters which were gotten from motor ID, although the values calculated from reactance(X) and the ones gotten from motor ID, they have great difference.

It confuses us that we get the correct parameters but the motor can not work well, could you give us more advice?

Best regards!

Brant Zheng 

In sensored mode for Induction Motors, the motor parameters are used for more than just the current loop tuning.  They are used to align the encoder to the motor's electrical angle.  In Induction machines, there is a continuous slip between the electrical angle and the motor angle.  In order to control one of these motors under load this slip needs to be estimated and the motor parameters are what allow us to do that.  

Adam,

Hi, Adam , I'm work with Brant, today I did a experiment about our motor ,

Frist I running program lab13e , and I set the gMotorVars.MaxVel_krpm to 3.25 which is the maximum speed of our motor. And then I add load to 20N.m, the motor running well as you can see the graphs:

Picture1. speed of our motor with 20N.m load 

Picture2. gMotorVars.IqRef_A from SpinTAC Velocity Controler

The rated torque of our motor can reach to 150N.m , but when I add the load around 70N.m , the motor start to run like Brant said , move and stop , move and stop ...

The speed and User_Iqref from SpinTAC Velocity Identify is unstable:

Picture3. speed of our motor with 70N.m load 

Picture4. gMotorVars.IqRef_A from SpinTAC Velocity Controler with 70N.m load

On the other hand ,  I  define USER_MOTOR_Ls_d  to  (0.000299644) which is read from our motor nameplate ,the motor only can drive 5N.m load. And I define USER_MOTOR_Ls_d   to  (0.000040) which is experimental results I did lots of times , the load can reach to 70N.m .

As I can see , it is the Oscillation of User_Iqref cause the problem ,and User_Iqref come form SpinTAC Velocity Controler:

and USER_MOTOR_Ls_d may influence the SpinTAC Velocity Controler,so it will be so nice that you can give me the code about SpinTAC Velocity Controler.

Best regards.

Stefan.

Stefan,

For sensored induction motor control the Lsd value is used to setup the slip compensator, so changing that value will cause issues for control since the slip compensator won't be able to estimate the magnetic angle of the motor.  The more load that is applied to the induction motor, the more slip that the motor will experience.  My guess is that once you get enough load the slip isn't estimated quite correctly.

Was the value of 0.00004 for USER_MOTOR_Ls_d determined by the motor parameter estimation in FAST?

Did you also identify the system inertia from lab 12a?

Adam,

Thanks for your reply , really, the problem we are stuck here more than a month .

Did you also identify the system inertia from lab 12a?

 I did  identify the system inertia from lab 12a .

Was the value of 0.00004 for USER_MOTOR_Ls_d determined by the motor parameter estimation in FAST?

No, I found that the lower  USER_MOTOR_Ls_d  is , the greater load can be drive, and should not less than0.00004 . 

My guess is that once you get enough load the slip isn't estimated quite correctly.

I know the load  will lead to changes in slip ,so how do I determine the problem on the slip compensator ?

For now I can call the function of EST_getFslip (),and see the change of slip,and what‘s the next step?

And on the other hand , Chris said that "(48) lines isn't valid for an encoder lines, it should be much higher." , is that  true ? 

Best regards.

Stefan

Hello Adam and Chris,

Thank you for your help.

I'm agree with you that the "wrong" motor parameters cause the wrong estimation of  the motor's electrical angle by FAST. But  the motor parameters are provided by our motor supplier. That confused us a lot.

And this issue reminds me an other issue which we met before. We could not pass through the motor ID and we discussed with you on E2E many times. The conclusion was that  this motor solution still had defect in ID high current ACIMs. Can I surmise that the problem which exists in ID high current ACIMs causes the issue of wrong estimation of  the motor's electrical angle?

According to your answer, is this the only way that we get the motor parameters which are correct for the FAST?  

Best regards,

Brant Zheng

Stefan,

The slip compensator runs inside SpinTAC Position Converter.  You should be able to view its output by looking at st_obj.pos.conv.SlipVel.

48 lines on the encoder is very small.  This means you only have 96 counts electrical cycle.  This is not great resolution.  Typically the lower end of encoders will have 1000 lines.  Giving 2000 counts per electrical cycle.

Hello Adam and Chris,

Thanks for the help. 

1. We replaced an encoder lines with 1024 lines, but make no difference.

2.I add runRsOnLine() to the for(;;) loop  and run the motor , this time , the motor just drop its velocity instand of "stop and move , stop and move". And gMotorVars.IqRef_A jump to USER_MOTOR_MAX_CURRENT  right away. it is inapprehension when gMotorVars.IqRef_A j run up to Maximum value but get lower velocity .The load is still Half of the ratings.

3. The value of  (0.000299644) for USER_MOTOR_Ls_d seems correct, because when running program lab12b, gMotorVars.Speed_krpm ≈ gMotorVars.SpeedQEP_krpm-0.05krpm. But it is also inapprehension that define USER_MOTOR_Ls_d to 0.00004 ,the motor can drive more load with  gMotorVars.Speed_krpm ≈ gMotorVars.SpeedQEP_krpm-0.3krpm.

4.If there is a incorrect motor parameters ,  how can we find it through poorly targeted measures ?

Chris,

Picture.1 is graph of gMotorVars.SpeedQEP_krpm when load add to motor from 0N·m to 100N·m,and Picture.1 is graph of gMotorVars.IqRef_A. 

Picture.1 graph of gMotorVars.SpeedQEP_krpm 

Picture.2 graph of gMotorVars.IqRef_A 

And as you can see after 80N·m load add to motor , the motor slow down and because of the calculation of SpinTAC Velocity Controler , gMotorVars.IqRef_A  start increasing, and hold to 60.8 which is the value of USER_MOTOR_MAX_CURRENT, but the motor speed still can't back to 3.2krpm.

So we did another test.

 In torque mode of lab4, we set gMotorVars.IqRef_A to 20A, the motor speed start rising , then we increase the load , the speed dropping, then we increase gMotorVars.IqRef_A, the speed rising , then we increase the load... , after several rounds, no mater how we increase gMotorVars.IqRef_A , the motor speed can't rise anymore,  and we increase the load again , the speed dropping. And gMotorVars.IqRef_A which could be 60.8 seems no effect after 30A. 

So maybe there is a limiting quantity about current PI controller(Picture.3) , so could you check the inside code of current PI controller or "INV PARK" and see if there is a limiting quantity , and the limiting quantity may related to user.h. Thank you.

Picture.3  current PI controller

Chris,

Thanks a lot for your help.

  Using the encoder, have you found any values of Ls and Rr that give pretty good performance results?

No, We replaced an encoder lines with 1024 lines, but the motor still can not drive load more than 80N·m.

But, I do believe there is a limiting quantity of the torque current output  , and also believe we have incorrect motor parameters. 

Today we make great progress, I cut the value of USER_MOTOR_MAGNETIZING_CURRENT slowly ,from (30.5) to (10), and the motor seems developed well.Now the motor can drive 150N·m(rated Torque ) much than 80 N·m .So the parameter USER_MOTOR_MAGNETIZING_CURRENT can limit the output of  motor Torque.

The speed still has a little shock and appear the same phenomenon(move and stop)  when drive more than 150N·m load (I thought the speed would fall).

Is the optimized parameters can solve the vibration of speed ?And why tspeed can not stable when the load overrate.

We have another question , the motor efficiency has only 40%-50% efficiency which usually is 70%-80%, I have no idea about it, could you give me more advice？

Here is the best parameters we groped, see the user.h

2664.user.h

Hello Chris,

The encoder we used can provide only signal A and signal B, no signal I. Can it cause this issue of wrong alignment of the magnetic to mechanical angle?

Hello Chris and Adam,

Thank you for your help.

Regarding low efficiency and insufficient output power,  we agree that there is something wrong with the alignment of the magnetic to mechanical angle. We worked on the motor parameters for nearly one month, the performance of the ACIM can be finitely improved, but the problem is still not solved.

As we kwon, the FOC for the induction motor drive can be mainly categorized into two types: indirect and direct schemes. InstaSPIN-FOC uses the direct FOC control, trying  to directly estimate the electrical angle based upon the measurements of terminal voltages and currents. But it is sensitive to motor parameters.

For most practical application, they use the indirect FOC control. It uses a current model to provide the electrical angle. We find the TMS320f28035 use this technology.

If it is appropriate, we want to try the indirect FOC control to control the low voltage and high current ACIM. Can 28069M do this? Or should we use an Evaluation Kit based on 28035 to have a try? 

Brant,

Since you are using an encoder to control the ACIM, the differences between InstaSPIN and the diagram you provided above are minimal.

The Current Model block is used to estimate the magnetic angle of the motor, this must use the motor parameters in order to do this.  In InstaSPIN this is accomplished with SpinTAC Position Converter.  That block takes in the Iq and Id references in order to estimate the slip in an ACIM, and uses that estimated slip to convert the encoder electrical angle to a magnetic angle.

The estimated angle from FAST is not used in any of the labs that use an encoder.

So I don't see any difference in the diagram that you show as compared with the FOC that is implemented as part of Lab 13e.

Our latest user.h

7357.user.h

The present situation is that the motor can provide only half the max torque with 40-50% efficiency.

Hello Adam,

Your analysis is quite reasonable, but we still suspect that there is something wrong with the estimation of slip or rotor flux position. The rotor flux is not aligned with d-axis and Isd and Isq are incorrect flux and torque components of the stator current, which cause the insufficient output torque and low efficiency.

In addition to adjusting the motor parameters in user.h, are there other ways to adjust the estimation? 

Best regards.

Brant

Yes.

Hello Chris,

We tried to increase the Iq in lab4(create a torque control ). But when Iq gets to a certain value, it seems to be ineffective to increase and can not provide more torque. At that time, if we increase the load, the motor speed will fall down.

In lab12b, we tried to increase the USER_MOTOR_MAX_CURRENT and decrease the USER_MOTOR _MAGNETIZING_CURRENT, to provide larger peak Iq current. In this way, the motor can provide more torque, but this improvement is limited.

We still suspect that there is something wrong with the estimation of slip or rotor flux position. The rotor flux is not aligned with d-axis and Isd and Isq are incorrect flux and torque components of the stator current, which cause the insufficient output torque and low efficiency.

In addition to adjusting the motor parameters in user.h, are there other ways to adjust the estimation?

Best regards.

Brant

Hello Chris,

Do you think the way we used to sample the feedback current and voltage may cause this issue? We use a total isolated sampling method. Maybe the slight phase delay?

Our hardware schematic diagram. 8875.Voltage&Current FB.PDF

But we have done many experiments with both 8301EVM and our board, the results are the same that the motor loses control at the similar load point in lab13e.

Best regards.

Brant

Hello Chris,

Can I  update the motor parameters when the motor is running ?

I modify the code like this:

					if(abs(gMotorVars.MaxVel_krpm)<=_IQ(1.75))
					{
						ctrlHandle->motorParams.Ls_d_H = USER_MOTOR_Ls_d;
						ctrlHandle->motorParams.Ls_q_H = USER_MOTOR_Ls_q;
						ctrlHandle->motorParams.Rr_Ohm = USER_MOTOR_Rr;
						ctrlHandle->motorParams.Rs_Ohm = USER_MOTOR_Rs;
						ctrlHandle->IdRated = _IQ(USER_MOTOR_MAGNETIZING_CURRENT/USER_IQ_FULL_SCALE_CURRENT_A);
					}
					else
					{
						ctrlHandle->motorParams.Ls_d_H = USER_MOTOR_Ls_d_update;
						ctrlHandle->motorParams.Ls_q_H = USER_MOTOR_Ls_q_update;
						ctrlHandle->motorParams.Rr_Ohm = USER_MOTOR_Rr_update;
						ctrlHandle->motorParams.Rs_Ohm = USER_MOTOR_Rs_update;
						ctrlHandle->IdRated = _IQ(USER_MOTOR_MAGNETIZING_CURRENT_update/USER_IQ_FULL_SCALE_CURRENT_A);
					}

but it did not work , so what I miss ?

Chris,

As we can see , the User_SpdRef is the motor velocity we set : gMotorVars.MaxVel_krpm,and in sensored systems , the Speed feedback we get is gMotorVars.SpeedQEP_krpm.  So the SpinTAC motion provide User_IqRef, that is Speed loop control , correct ?

But I am little confused about the Id PI controller , which is the variable of User_IdRes in the program of lab13e?

I can only find this , but I can not understand it .

     // compute the reference value
     refValue = TRAJ_getIntValue(obj->trajHandle_Id) + CTRL_getId_ref_pu(handle);

     // update the Id reference value
     EST_updateId_ref_pu(obj->estHandle,&refValue);

The Rs change caused the effect  of Irated from FAST,  correct ?  Is the Irated has restrictions ?

Chris,

As mentioned in spruhj1f.pdf , “For applications that require minimum power consumption using AC Induction Motors (ACIM) PowerWarp presents a solution. By simply setting an enable flag in InstaSPIN-FOC, the FAST estimator will recalculate the magnetizing current, so that the minimum current is used to produce the torque needed for a given load and speed.”.

And we can enable it by setting gMotorVars.Flag_enablePowerWarp to  TRUE , and the motor runs well .But when we set it to false , the current become high and the motor can not run normally , why can't I set it to false ? Is it necessary ?

Adam,

As you metioned  ： "The more load that is applied to the induction motor, the more slip that the motor will experience.  My guess is that once you get enough load the slip isn't estimated quite correctly.", and here is my understanding ：

1. we need enc->enc_magnetic_angle for PARK 

2.Flux angle = Mechanical angle *  pole-pairs + slip angle , and slip angle ： θ=∫(ωs )dt .

in the code :

enc->enc_slip_angle = enc->enc_slip_angle + enc->incremental_slip;

slip->incremental_slip = _IQmpy(slipVelocity, slip->sample_time);

and slipVelocity is come from SpinTAC .

3. My guess in SpinTAC , the fuction STPOSONV_run() use this formula to get slipVelocity:   ωs=Iq/(Tr * Id ) , Tr = Lr/Rr , correct ?  And Iq,Id,slipVelocity is Iterative relationship . right ?

4.So if I am right ,  wrong motor parameter will cause the slip compensator estimate wrong slip angle , correct ?