Problem with instaSPIN-FOC and SpeedRef_krpm = 0.0

Hello,

Based on User Guide of InstaSPIN-FOC and InstaSPIN-MOTION (spruhj1a),

Chapter 15  Managing Full Load at Startup, Low-Speed and Speed Reversal --> 15.2  Low Speed Operation with Full Load  --> chapter 15.2.1.3 Disable Forced Angle, it is mentioned:

"When running in low speeds, forced-angle must be turned off in order to allow the estimator to converge to
the estimated values with no intervention of an external angle being forced"

Have you tried to turn OFF Flag_enableForceAngle?

Do you have load on your motor?

I am also still learning. I think TI expert will answer you soon.

Best regards,

Maria

As Maria noted, if experimenting AT zero speed, to use FAST feedback the ForceAngle should be off. It should be on if you want to move FROM zero speed.

But I think there could be a couple other things to look at:

- Speed Controller. Seems like the integrator is winding up and giving an output torque request. I'd look at tuning this a bit. Lower the Kp and Ki.  Or try InstaSPIN-MOTION.

- Estimator: with the rotor not moving there isn't Bemf into FAST, so the estimation will start to drift. If the motor has larger Bemf this will be lower. If there is a load on the motor it will be lower and any torque commands will have less effect on the actual motion. 

It would be interesting to look at the speed estimate (coming from FAST and into the Speed PI) and the speed control output (the Iq_ref) going into the Iq controller during this event.

Thanks for your answers.

I tried with ForceAngle = off but the problem still appears.

Currently, there is no load on the motor and I haven't changed the PI coefficients calculated.

In the picture below, you will see all the parameters in gMotorVars structure when the problem occurs (and I think the parameters you would like to look at):

// get the speed estimate gMotorVars.

Speed_krpm = EST_getSpeed_krpm(obj->estHandle);

// read Id and Iq vectors in amps gMotorVars.

Id_A = _IQmpy(CTRL_getId_in_pu(ctrlHandle), _IQ(USER_IQ_FULL_SCALE_CURRENT_A));

Iq_A = _IQmpy(CTRL_getIq_in_pu(ctrlHandle), _IQ(USER_IQ_FULL_SCALE_CURRENT_A));

// calculate vector Is in amps

 Is_A = _IQsqrt(_IQmpy(gMotorVars.Id_A, gMotorVars.Id_A) + _IQmpy(gMotorVars.Iq_A, gMotorVars.Iq_A));

Hello,

Does this happen only when the SpeedRef = 0?

I am wondering, when you increase (or try with slightly increase) the SpeedRef, does the speed follow the SpeedRef?

decrease your Kp_spd. Try decreasing it even when it is happening.

I can reproduce this even with the 24V/4A Anaheim motor. With a command of zero speed and no load, if you increase the Kp_spd gain too high the control loop becomes unstable and starts hunting (the speed estimate is quickly going back and forth around +/- 400 RPM)  

In my example Kp_spd of 8 is stable, but 12-20 (depending on existing angle alignment I think) pushes it into instability

Hello,

Yes Maria, it happens only when the speed is 0. The speed follows SpeedRef until 25rpm.

I'm sure, the problems come from the speed regulator but I don't know why :

- When the problem appears (Speed around 200rpm with Iq_Ref max following User.h), Kp_spd = 0 has no effect, Ki_spd = 0 has no effect and a new SpeedRef has no effect.

- To stop the motor, I have to put Flag_enableSys as false or disable the speed regulator

- With a command of zero speed and no load, the control loop becomes unstable with a Kp_spd around 25. The calculated Kp_spd is 3.8. The problem occurs even with a Kp_spd = 0.5.

Sebastien,

Does this happen immediatly upon starting up for the first time?

I'm thinking the Rs estimation is incorrect. If you have been running loaded (which it appears you may be as you say you have Iq maxed out to your user.h limit) then the resistance may increase due to higher current. If this is the use case of your motor you will have to run the Rs Online, continously tracking the Rs changes.  Rs is the dominant motor parameter at low speed (Ls is the dominant at high speed).

To test this theory you can try directly increasing your Rs in your user.h in 10-20% increments to see if you can remove this issue.  You will still need to tune your speed controller.

You can also try stopping the motor when the issue occurs and then starting immediately with RsRecal enabled to see how the Rs might be changing.

Again though recall, this is not a 0 speed observer. You should have methods to start from 0 speed and move through 0 speed, but it should not be expected to stay at 0 speed for extended periods.  For extended 0 speed sensorless you need different techniques (injection or saturation is common).

Hello Chris,

I tried the test with Rs and here is the result:

Rs estimation = 0.233976 (motor's specification said 0.363 ohms phase to phase resistance)

I tried with Rs = 0.2807712 (so + 20%) and the problem still appears.

When the problem appeared, the Rs value had reached 0.470. So I stopped the motor and started it again with RsRecal enabled and the Rs value went down until 0.265.

I don't known if it's the same problem, but time to time when I start from 0 to 3000rpm there is a few seconds delay before the motor is spinning.

Is it possible to change dynamically some motor parameters ?

For example:

- I would like to change the maximum current. I can modify this value in "gUserParams" structure but this change is not take into account.

- I would like to change the user motor, switch between Anaheim_BLY172S and Estun_EMJ_04APB22. Is it possible?

The function "USER_setParams"

"Rs estimation = 0.233976 (motor's specification said 0.363 ohms phase to phase resistance)"

The Rs we use is phase to neutral, so divide 0.363/2 = 0.1815.  Means your Rs at nominal temp is still like 28% over what is spec'd. This is what makes sensorless observor based algorithms challenging unless you actually monitor the ture Rs.

"When the problem appeared, the Rs value had reached 0.470."

How do you know it reached 0.47?  Did you stop and RsRecal right away?  Doubling your Rs is a huge change, and it isnot surprising that your angle estimation from FAST is no longer valid.  The observer model is no longer correct.  You will certainly need to use RsOnline feature to continuously monitor the Rs change.

"So I stopped the motor and started it again with RsRecal enabled and the Rs value went down until 0.265."

How much time passed from when the motor was loaded to when you recal'd? It is surprising that it would go back to nominal Rs after only a few seconds.  Temperature doesn't typically change that quickly in the stator.

What is the Ls, Flux, Voltage, and current of this machine?

"I don't known if it's the same problem, but time to time when I start from 0 to 3000rpm there is a few seconds delay before the motor is spinning."

Is RsRecal and OffsetRecal DISABLED?  If so, it should ATTEMPT to start-up immediately.
Is ForceAngle Enabled?  It should be for a zero speed starte. There are some acceleration rates that can be set in the user.h  to make this go faster.

Is your Accleration variable set high enough?

Is this being tested with a load?  Can you try it in Torque mode without the speed loop? It's possible the speed loop is taking too long to request enough torque to overcome any start-up load. You will have to increase the gain.  The SpinTAC feature of InstaSPIN-MOTION has also been proven to give faster start-up capability, but you shouldn't be seeing seconds of delay.

I believe it is Chapter 15 of the UG that discusses start-up capability.

"- I would like to change the maximum current. I can modify this value in "gUserParams" structure but this change is not take into account."

.Yes, you can load any of the settings into the Estimator handle whenever required. You can do this through structures, or directly.

For structures, you'll notice we have the following two in the MotorWare projects

  // initialize the user parameters
  USER_setParams(&gUserParams);

  // set the driver parameters
  DRV_setParams(drvHandle,&gUserParams);

  // initialize the controller
#ifdef FAST_ROM_V1p6
  ctrlHandle = CTRL_initCtrl(ctrlNumber, estNumber);    //v1p6 format (06xF and 06xM devices)
#else
  ctrlHandle = CTRL_initCtrl(estNumber,&ctrl,sizeof(ctrl)); //v1p7 format default
#endif

  controller_obj = (CTRL_Obj *)ctrlHandle;

// set the default controller parameters
  CTRL_setParams(ctrlHandle,&gUserParams);

The easiest thing to do is to change the data in gUserParams and re-set these handles.

But if you look in softwareUpdate1p6() function you will notice that for this update we set the estHandle directly (these values normally get passed from the gUserParams through the USER to the EST)

  // store the results
  EST_setLs_d_pu(obj->estHandle,Ls_d_pu);
  EST_setLs_q_pu(obj->estHandle,Ls_q_pu);
  EST_setLs_qFmt(obj->estHandle,Ls_qFmt);

"- I would like to change the user motor, switch between Anaheim_BLY172S and Estun_EMJ_04APB22. Is it possible"

Why would you want to do this on the fly? That isn't a good idea. You can certainly load in a new structure of parameters for another motor when you are idle. Also, one of these is a low voltage, the other high voltage...this request doesn't make much sense.

Hello Chris,

I know Rs reached 0.47 by watching gMotorVars.Rs_Ohm and gMotorVars.RsOnLine_Ohm (both values are identical) on the expression window.

I tried with RsRecal enabled but the problem still appears.

Here is the identification of the 3 motors I'm testing :

#elif(USER_MOTOR == Maxon_EC90Flat)

#define USER_MOTOR_TYPE                 MOTOR_Type_Pm

#define USER_MOTOR_NUM_POLE_PAIRS       (12)

#define USER_MOTOR_Rr                   (NULL)

#define USER_MOTOR_Rs                   (0.1815)//(0.233976)

#define USER_MOTOR_Ls_d                 (0.000132)

#define USER_MOTOR_Ls_q                 (0.000132)

#define USER_MOTOR_RATED_FLUX           (0.02173)

#define USER_MOTOR_MAGNETIZING_CURRENT  (NULL)

#define USER_MOTOR_RES_EST_CURRENT      (1.0)

#define USER_MOTOR_IND_EST_CURRENT      (-0.8)

#define USER_MOTOR_MAX_CURRENT          (5.39)

#define USER_MOTOR_FLUX_EST_FREQ_Hz     (20.0)

#elif(USER_MOTOR == Vexta_BLHM5100)

#define USER_MOTOR_TYPE                 MOTOR_Type_Pm

#define USER_MOTOR_NUM_POLE_PAIRS       (5)

#define USER_MOTOR_Rr                   (NULL)

#define USER_MOTOR_Rs                   (0.149280)

#define USER_MOTOR_Ls_d                 (0.000450565)

#define USER_MOTOR_Ls_q                 (0.000450565)

#define USER_MOTOR_RATED_FLUX           (0.05296522)

#define USER_MOTOR_MAGNETIZING_CURRENT  (NULL)

#define USER_MOTOR_RES_EST_CURRENT      (1.2)

#define USER_MOTOR_IND_EST_CURRENT      (-0.8)

#define USER_MOTOR_MAX_CURRENT          (6.00)

#define USER_MOTOR_FLUX_EST_FREQ_Hz     (20.0)

#elif(USER_MOTOR == SPG_BLDC100W)

#define USER_MOTOR_TYPE                 MOTOR_Type_Pm

#define USER_MOTOR_NUM_POLE_PAIRS       (5)

#define USER_MOTOR_Rr                   (NULL)

#define USER_MOTOR_Rs                   (0.1113523)

#define USER_MOTOR_Ls_d (0.0002122781)

#define USER_MOTOR_Ls_q                 (0.0002122781)

#define USER_MOTOR_RATED_FLUX           (0.05597881)

#define USER_MOTOR_MAGNETIZING_CURRENT  (NULL)

#define USER_MOTOR_RES_EST_CURRENT      (1.2)

#define USER_MOTOR_IND_EST_CURRENT      (-0.8)

#define USER_MOTOR_MAX_CURRENT          (6.00)

#define USER_MOTOR_FLUX_EST_FREQ_Hz     (20.0)

I'm having the same problem with all these 3 motors.

Regarding the delay I noticed (time to time) when I want to start the motor from 0 to 3000rpm :

RsRecal was disabled, OffsetRecal was enabled, ForceAngle was enabled, acceleration rate was 10.0 krpm/s and there was no load on the motor. I haven't had any problems in torque mode. Currently, when my position regulation is finished, I put the system in torque mode (to be sure i won't have the problem at zero speed during a long time). When I want to move to another position, first I put the system in speed mode. It's the only one solution I have found until now.

I tested to change the maxCurrent in gUserParams structure after that disable gMotorVars.enableSys and disable gMotorVars.Run_Identify and then enable them again and it works but I would like to modify this parameter without to have to disable the system. I didn't find an estimator function to be able to modify directly the estimator handle. It seems this parameter is only used for the Kp and Ki of the PID speed controller. So I tried to change Kp and Ki like it is done in the function called "calcPIgains" (for the speed controller instead of the current controller) but it doesn't work.

I wasn't clear when I asked you how to change the user motor. As you noticed in the beginning of this post, I'm testing 3 differents motors in my system and I would like to switch between one to another without to have to change the code. I didn't find the user motor in the structure gUserParams. Shall I have to create a new structure with the parameters of these 3 motors and then change gUserParams according to the motor selected (of course disable and enable the system to update handles)?

Hello Chris,

I'm coming back to you regarding how to change the maximum current on the fly.

I tested to change the maxCurrent in gUserParams structure after that disable gMotorVars.enableSys and disable gMotorVars.Run_Identify and then enable them again and it works but I would like to modify this parameter without to have to disable the system. I didn't find an estimator function to be able to modify directly the estimator handle. It seems this parameter is only used for the Kp and Ki of the PID speed controller. So I tried to change Kp and Ki like it is done in the function called "calcPIgains" (for the speed controller instead of the current controller) but it doesn't work.

Do you have an idea how I could do that?

Sebastien,

First, I've asked some others for thoughts on your zero speed issue, waiting on feedback.

For the USER_MAX_CURRENT, the only place it is used is

1. to set the maximum allowable output for the Speed PI controller 

2. to initialize the gains for the Speed PI controller

This thread discusses how to change the speed PI

http://e2e.ti.com/support/microcontrollers/c2000/f/902/t/296202.aspx

Thanks a lot chris.