Problem with lab 12a Instaspin

So lab 12a is the first time you've used the QEP right?

In the labs with QEP, the QEP is used to derive the electrical angle (in FOC it is the estimator).

The code to "offset" correctly the ENC module such that the electrical angle is correct is not so good. We had to write our own electrical angle function which looked at our motor's five Hall sensors. Then combine that with the QEP's angle to create a solid electrical angle.

So in my experience, this part doesn't work:

// if we are forcing alignment, using the Rs Recalculation, align the eQEP angle with the rotor angle
if((EST_getState(obj->estHandle) == EST_State_Rs) && (USER_MOTOR_TYPE == MOTOR_Type_Pm))
{
ENC_setZeroOffset(encHandle, (uint32_t)(HAL_getQepPosnMaximum(halHandle) - HAL_getQepPosnCounts(halHandle)));
}

Let me know if you want more details.
Rich

Borja,

So when you try to run the inertia identification, the motor will spin for a short time but will always report the 2003 error. Correct?

You are still performing the Rs Recalibration at startup correct? For the labs this is how we align the motor and the encoder angles.

If you run multiple inertia identifications in a row without stopping the processor or disabling the drive, will the motor spin each time?

I'm thinking that it might not be the encoder configuration, but could be a Ramp Time setting issue. What is the smallest Ramp Time that you have tried. For motors with large friction or cogging force we need a smaller Ramp Time.

Dear Adam,

So when you try to run the inertia identification, the motor will spin for a short time but will always report the 2003 error. Correct?

Yes. It spins for 1 second and then stops.  I have reduced the time from 5s to 4s, 3s, 2s and finally 1s. With 1 second, the error disappear, but the inertia is not correct (0.03 instead of 0.35). The motor does not reach the target speed for inertia identification (1500rpm). Using this values in the following lab (12b), the motor does not perform any movement.

If you run multiple inertia identifications in a row without stopping the processor or disabling the drive, will the motor spin each time?

It always spins some turns, but never reach the target speed

You are still performing the Rs Recalibration at startup correct? For the labs this is how we align the motor and the encoder angles.

Yes. The motor always spins to align with encoder angle. In fact, the encoder has also an absoute position output and the angle obtained after multiple RS recalibrations seems to be coherent. Is there any other way to verify that alignment has been correctly performed?

I'm thinking that it might not be the encoder configuration, but could be a Ramp Time setting issue. What is the smallest Ramp Time that you have tried. For motors with large friction or cogging force we need a smaller Ramp Time.

 I have reduced the time from 5s to 4s, 3s, 2s and finally 1s, but the results are not good.

Just, one doubt: Prior to the inertia identification, if we set EnableSystem and Run_Identify flags the motor should spin. Is this true?. The motor does not spin in fact, the current demanded by the power supply is quite small (It seems that system is idle)

Thank you in advance.

 

 

Dear Rich,

We have run this lab multiple times with other motor without problem. We usually use a dual encoder with quadrature signals and absolute position signal. This absolute encoder could gives some clues about the "goodness" of the alignment (the recalibration must be done multiple times at the recalibration period, but once this calibration is done, we just read the absolute position and using the previous data the offset can be infered). With this motor, the position read after any Rs recalibration seems to be OK, so it doest not seems to be a recalibration problem.

Thank you

Borja

Ah okay.

In my application we must have 100% torque from zero speed (so can't use FAST) and do not have time at startup to do RsOffline - so alignment can only be from sensors.

Good luck!

Rich

i heve same problem

Borja,

Borja Gomez88 said:

With 1 second, the error disappear, but the inertia is not correct (0.03 instead of 0.35).

Are you comparing the inertia value from lab 5c with the value you have identified with lab 12a?

Borja Gomez88 said:

Using this values in the following lab (12b), the motor does not perform any movement.

Have you tried increasing the bandwidth when running this lab?  What happens if you use the 0.35 value for inertia?

Borja Gomez88 said:

It always spins some turns, but never reach the target speed

It seems then that you encoder is working correctly.  You might need to decrease the ramp time even smaller.  It can be reduced as low as the speed loop sample time.

Borja Gomez88 said:

Prior to the inertia identification, if we set EnableSystem and Run_Identify flags the motor should spin. Is this true?

In lab 12a, the motor won't spin prior to inertia identification.  In lab 5c, we need to spin the motor in order to keep the FAST software encoder estimating a good speed.  Since we have the encoder in lab 12a we don't need to run the motor.

Dear Adam,

Are you comparing the inertia value from lab 5c with the value you have identified with lab 12a?

Yes. 

It seems then that you encoder is working correctly.  You might need to decrease the ramp time even smaller.  It can be reduced as low as the speed loop sample time.

I have reduced the ramp time (gMotorVars.SpinTAC.VelIdTorqueRampTime_sec ) to 0.1 seg and Inertia identification has been performed without error. t

Values for lab 12a

#define USER_SYSTEM_INERTIA (0.59152776)
#define USER_SYSTEM_FRICTION (6.464028895)

Values for lab 5c

#define USER_SYSTEM_INERTIA (0.3361109495)
#define USER_SYSTEM_FRICTION (1.48310554)

I have used this values for lab 12b. The motor is tighly fixed to 0rpm speed with a bandwith value of 5.0 (gMotorVars.SpinTAC.VelCtlBwScale). If a change the reference speed from 0rpm to any other value (for instance, 100rpm) the motor tries to run at this reference speed but the movement is not soft (please see image below)

I have to reduce the bandwith to 0.5rad/s in order to have a soft speed, but with this value the control is not strong enough. Sensorless lab (5f) has good results with 5 and 10 rad/s.

Any clue,

Thank you in advance,

Borja.

Borja,

I'm glad to hear that the inertia identification is working.  I think the issue you are seeing is a minimum resolution issue.  With 512 encoder lines, and assuming that your speed loop runs at 1ms, you have an effective resolution of 30 rpm from your encoder.  This will make it difficult to control speeds much below 300 rpm.

MotorWare only implements the pulse counting method of speed calculation, if you desire more accurate speed calculation at low speeds you can either decrease the speed loop sample time or implement the pulse timing method of speed calculation.

Adam,

I have tested the motor with a higher resolution encoder (2048) and results seems to be better. Previously, I needed to reduce ramp time to 0.1 in order to have no error during the inertia identification. Now, the identification is made with no issues (t = 5s speed =1500rpm)

Lab 5c
#define USER_SYSTEM_INERTIA (0.3361109495)
#define USER_SYSTEM_FRICTION (1.48310554)
Lab 12a
#define USER_SYSTEM_INERTIA (0.373322575)
#define USER_SYSTEM_FRICTION (1.4101234)

but now, I have another problem. I had run this labs just to verify that motor and encoder worked ok, but now I have to fix the real inertia to the motor . This motor is used in a power assisted steering system and the steering wheel is directly fixed to the motor axle. The lab 12a is made without no error (inertia is a little bit high, but i suppose this is due to the steering wheel (diameter = 310mm))
#define USER_SYSTEM_INERTIA (63.79553974)
#define USER_SYSTEM_FRICTION (3.239408374)
Lab 13a is quite suitable for the power assited steering. The system has to return to it 0 position when the driver does not opposite enough torque. This is a position control with a fixed reference in 0º and limited torque. I tried to tune the controller, but if i increase the bandwith behind 1, the system starts to oscillate. Reducing the bandwidth, the control is not strong enough to fix the position in 0º tightly. Probably this is related to the system high inertia.

How can I proceed to tune the control? Is there any problem with this high inertia apps?

Thank you in advance

Borja

Borja,

That is a huge inertia.  My thought is that due to the torque limitation, this is causing the controller to saturate and go into oscillation when you increase the bandwidth since the controller knows about the inertia it is going to try to use as much torque as it can in order to get the position back to the 0 position.  Since that is fairly limited, it will cause the system to saturate at that limitation and when it overshoots the goal position, it will need to immediately reverse the torque in order to stop the motor, where it will then overshoot again, and so on.

What I've seen/heard about electric power assist steering is that it is typically a torque control application and not necessarily a position control application, but I don't have much expertise in that space.