28069 starting torque issue

Using ForceAngle just until motor starts (disabling as soon as it does) , and adjusting the "0.5" Hz value for your motor/system in:
#define USER_ZEROSPEEDLIMIT (0.5 / USER_IQ_FULL_SCALE_FREQ_Hz)

will allow you to generate peak currents during start-up of
USER_MOTOR_MAX_CURRENT

make sure this max_current value is large enough for your load.

for example, try 1.0, 2.0, 4.0, 6.0 Hz and see if it improves. You should be able to get reliable - though maybe not especially smooth - start-up.

you should also review SPRUHJ1 chapter 14

to improve on the start-up beyond that you would need to use rotor sensors. In MotorWare v16 (releasing this week) there is an example for your kit which uses hall sensors for initial start-up with a user set transition point to FAST for sensorless operation thereafter.

Hi Chris,

thank you for your answer. Actually, I have already tried out changing the value 0.5 in the parameter USER_ZEROSPEEDLIMIT. Unfortunately, this didn't really change the starting current of 2,3 amps. In fact, it's even possible to hold the motor just with one hand and the torque doesn't exceed 2.5Nm. This should be much more during startup (7Nm, according to datasheet). USER_MOTOR_MAX_CURRENT is set to the highest possible value. What we can observe is that, as the motor tries to start spinning with load, it moves forwards and backwards for short distances. The Force-Angle function doesn't influence the starting current either.

Since a solution with hall sensors would be a huge effort for us to implement, we are keen on the sensorless solution. Are there any other ways to increase the starting torque that we might have forgotten to consider?

Regards,
Lukas.

did you implement anything from SPRUHJ1 chapter 14?

increasing RES_EST_CURRENT to align the rotor to the stator will certainly help

Hi again,

I've tried increasing the RES_EST_CURRENT value, unfortunately without success. Since the comment next to this value says „During Motor ID", I didn't even consider changing this value. This should be relevant for identification purposes only, shouldn't it?

I've had a look at the SPRUHJ1 chapter 14 section 14.3 „Motor startup with full load". The points mentioned there cover enabling offset recalibration, Rs recalibration, Forced Angle, tuning the speed controller and the voltage feedback circuit. Offset, Stator Rs and Forced Angle are enabled permanently in the GUI.

With regards to the controller, I've already tried changing the Kp and Ki values. If I make them to small, the motor does not even start at all or after a long delay time. If I make them to big, the motor makes high-frequent noises and won't start spinning properly. In both cases, the starting current doesn't go higher than the 2.3 amps. The last thing I tried was changing the USER_ADC_FULL_SCALE_VOLTAGE_V and the USER_VOLTAGE_FILTER_POLE_Hz (voltage controller), which didn't help either.

So far, everything works fine except the problem with the starting torque. After braking the spinning motor, the current rises until the maximum current (e.g. 15 amps) is reached. If the motor speed drops below a certain value, though, then the current suddenly decreases, reaching the limit of 2.3 amps at standstill.

Is there maybe a software limitation of the starting current? Any other paramteters? Could it be that the flux direction can't be determined below a certain motor speed? I have been looking for a solution for a long time now and would be very happy if it would finally work.

Thank you for the help so far.

Regards

"I've tried increasing the RES_EST_CURRENT value, unfortunately without success."

you need to enable gMotorVars.Flag_enableRsRecalc before gMotorVars.Flag_Run_Identify

"This should be relevant for identification purposes only, shouldn't it?"

No, as described in SPRUHJ1 it is a good practice to re-identify the Rs value before starting up a system. It also has the benefit - if enough RES_EST_CURRENT is supplied to move the existing load - to potentially align the stator to the rotor field to improve the initial torque production at start-up.

"Offset, Stator Rs and Forced Angle are enabled permanently in the GUI."

I'm not sure what this means. They are Flags which can be enabled/disabled.  Are you only using the InstaSPIN-FOC or -MOTION GUI? If so, that is for demonstration purposes only. For development please use the MotorWare labs.

"USER_ADC_FULL_SCALE_VOLTAGE_V"

in most cases this should be set to your Vbus level

"USER_VOLTAGE_FILTER_POLE_Hz"

you should never change this, it is HW dependent.

"Is there maybe a software limitation of the starting current? Any other paramteters? Could it be that the flux direction can't be determined below a certain motor speed?"

No. No. No.

Torque is determined by the accuracy of the angle and the maximum current. At zero speed you have no angle accuracy, so you need to get the motor to move so FAST can start getting "close" estimates, and then move the motor to a frequency in which FAST gives very good estimates.

"After braking the spinning motor, the current rises until the maximum current (e.g. 15 amps) is reached."

That is expected behavior

" If the motor speed drops below a certain value, though, then the current suddenly decreases, reaching the limit of 2.3 amps at standstill."

I would say that the motor has lost synchronization. What sort of electrical frequency?  FAST's ability to produce an accurate angle deteriorates the closer you get to zero speed.

Hi Chris,

thank you for your answer.

I've now enabled the RsRecalc before SystemIdentify. However, this flag seems to cause quite an arbitrary behaviour: In some cases, the motor spins very slowly (~5rpm), and in other cases, the motor starts properly to full speed. If we give the slow-spinning motor a push so a certain speed is exceeded, then the motor continues spinning by itself. If we disable ForceAngle, while RsRecalc is still activated, we cannot get the motor spinning to full speed, it then rotates with about 150rpm (rated speed should be >1000rpm). The torque, though,, is still not high enough. Could it be that the ForceAngle algorithm has problems with aligning the rotor to the stator field?

We can now observe the following behaviour (with RsRecalc and ForceAngle activated): If we can get the motor to spin at rated speed (which is not always the case, as mentioned above) and brake the motor, then the current rises to maxCurrent and we have the full torque. The maxCurrent is now still present at standstill, however, the torque is then almost zero, which should not be... After releasing the brake, the little toque is still able to accellerate the motor to a certain speed where the full torque can be generated again. Conclusion: Below a certain speed, the torque drops and is not linked to the current anymore. The other thing is that, if the current was initially zero and we activate the brake (simulates high load), then we reach the well-known limit of 2.3 amps again after increasing the current. In this case, we have a slightly higher torque than with the maxCurrent at standstill, but its still insufficient for our purpose.

"No, as described in SPRUHJ1 it is a good practice to re-identify the Rs value before starting up a system. It also has the benefit - if enough RES_EST_CURRENT is supplied to move the existing load - to potentially align the stator to the rotor field to improve the initial torque production at start-up."

RES_EST_CURRENT is now set TO the maximum value possible. Inside the GUI, i can see that the Rs (Ohm) value changes after startup, so I assume that RsRecalc works. However, I'm not sure whether this improves the alignment of stator and rotor field in my case...

"I'm not sure what this means. They are Flags which can be enabled/disabled. Are you only using the InstaSPIN-FOC or -MOTION GUI? If so, that is for demonstration purposes only. For development please use the MotorWare labs."

What I meant was that the flags (the checkboxes) RsRecalc, OffsetCalc and ForceAngle are enabled (the checkboxes are ticked) inside the GUI. They are all enabled before SystemIdent. I use the InstaSPIN-FOC univeral GUI and run the lab04a (torque mode).

"I would say that the motor has lost synchronization. What sort of electrical frequency? FAST's ability to produce an accurate angle deteriorates the closer you get to zero speed."

What do you mean by "sort of electrical frequency"? Since FAST is irresponsible for the torque at zero speed, I think that ForceAngle has troubles to accellerate the motor to the demanded speed where FAST can take over. As mentioned above, there might be something wrong with the alignment of the fields at standstill while having full torque.

Are there maybe example projects that are able to directly drive a motor with full load (to generate the maxmimum starting torque) without a bunch of variables that need to be changed first? Or anything else I could try out?

Thank you for the help.

Regards

"Could it be that the ForceAngle algorithm has problems with aligning the rotor to the stator field?"
ForceAngle does not align any fields. It produces a constantly incremented angle for use in the feedback system. That is all.

The only way to initially align the stator to rotor field at the beginning is to inject a large enough Id_Ref_A (using RsRecal is the easiest way) to mechanically move the rotor to alignment under the existing load. This may not be possible if the load is too large.

"The maxCurrent is now still present at standstill, however, the torque is then almost zero, which should not be... "
Shortly after stalling to zero speed the FAST observer will no longer be providing accurate angle information, which means that the torque production will be compromised. This behavior is expected.

You can activate ForceAngle during a stall to help you start up again (once the load is reduced)


"Are there maybe example projects that are able to directly drive a motor with full load (to generate the maxmimum starting torque) without a bunch of variables that need to be changed first?"
Starting a motor sensorlessly under full load - and restarting under overload/stall - is a tough challenge. I have outlined the best procedures we have to get the best results.

"The only way to initially align the stator to rotor field at the beginning is to inject a large enough Id_Ref_A (using RsRecal is the easiest way) to mechanically move the rotor to alignment under the existing load. This may not be possible if the load is too large."

Enabling RsRecal didn't really have a positive effect on the starting behaviour. What I could see inside the the gMotorVars was that the value for Idref_A and IdA never changed. Is there maybe a way to increase the required value for Id manually?

Overall, ForceAngle and RsRecal, which should improve starting behaviour, didn't increase either starting current (Imax = 2.3 amps) and starting torque. Is that normal? Shouldn't there be at least a little improvement in current/torque?

"You can activate ForceAngle during a stall to help you start up again (once the load is reduced)"

I thought that ForceAngle was activated automatically again below a certain motor speed (provided that the ForceAngle-flag is set)?

"Starting a motor sensorlessly under full load - and restarting under overload/stall - is a tough challenge. I have outlined the best procedures we have to get the best results."

I am aware that this task with a sensorless solution is quite challenging, but I hope that there is a way of solving this issue. That's the reason why we've chosen a solution with InstaSPIN, which should make a sensorless startup easily possible, according to the datasheet (compared to other solutions).

Regards

"What I could see inside the the gMotorVars was that the value for Idref_A and IdA never changed. Is there maybe a way to increase the required value for Id manually?"

while IdRef_A is in the gMotorVars structure, it is initialized to 0 and this variable is neither set or used in any lab before proj_lab09 (for field weakening). Meaning, when you do an RsRecal there IS a +IdRef_A applied equal to USER_MOTOR_RES_EST_CURRENT_A but you won't see any change to gMotorvars.IdRef_A

Yes, you can write some code for a state to manually set an IdRef instead of using RsRecal

"Overall, ForceAngle and RsRecal, which should improve starting behaviour, didn't increase either starting current (Imax = 2.3 amps) and starting torque. Is that normal? Shouldn't there be at least a little improvement in current/torque?"
USER_MOTOR_MAX_CURRENT != Imax

try increasing USER_MOTOR_MAX_CURRENT up to USER_ADC_CURRENT / 2 to increase the peak IqRef_A command.

When you run RsRecal before starting up do you see the rotor actually move? There needs to be a mechanical alignment.


"I thought that ForceAngle was activated automatically again below a certain motor speed (provided that the ForceAngle-flag is set)?"
No, there is a Flag to enable/disable ForceAngle.
IF ForceAngle is active then yes, when the estimated speed is < the frequency created from USER_ZEROSPEEDLIMIT then the angle in the forward control will be based on the ForceAngle, which is just an emulated rotating angle of a fixed frequency of USER_FORCE_ANGLE_FREQ_Hz. Which is not a good estimate. It should never be used for control. It can be used to force enough initial motion so that FAST can then take over.

"while IdRef_A is in the gMotorVars structure, it is initialized to 0 and this variable is neither set or used in any lab before proj_lab09 (for field weakening). Meaning, when you do an RsRecal there IS a +IdRef_A applied equal to USER_MOTOR_RES_EST_CURRENT_A but you won't see any change to gMotorvars.IdRef_A

Yes, you can write some code for a state to manually set an IdRef instead of using RsRecal"

I've been looking for a function to set the IdRef_A but couldn't find it. My USER_MOTOR_RES_EST_CURRENT_A should be set a high enough value to supply sufficient Id.

"try increasing USER_MOTOR_MAX_CURRENT up to USER_ADC_CURRENT / 2 to increase the peak IqRef_A command."

I couldn't find the variable USER_ADC_CURRENT in my user.h?
USER_MOTOR_MAX_CURRENT is set to 80 amps.

"When you run RsRecal before starting up do you see the rotor actually move? There needs to be a mechanical alignment."

If I activate RsRecal and click identify, then I can see that the value für Rs changes in the GUI. However, the motor doesn't move during this process. After RsRecal is finished, then I can run the motor, but only in some cases. Sometimes is spins slowly with full current and little torque. Sometimes I can get the motor spinning. but this arbitrary behaviour is unreliable and not suitable for our application.
If I disable the RsRecal, then everything works fine, except for the starting torque, if there no load, it starts in all cases, but as soon as little torque is required for startup (e.g. when we hold the motor with hand), it won't work.

We think that, at startup, the current is adjusted just in the wrong electrical axis (the d-axis). Therefore, the current responsible for the flux is at maximum, but the current responsible for the torque generation (q-axis) is insufficient. This little torque may just be enough for the motor to start spinning, but only if there is no load.

"It can be used to force enough initial motion so that FAST can then take over."

Could it be that special motor requirements must be met for the ForceAngle algorithm? Based on experiences, what are the average starting torques that can be reached with ForceAngle at startup? Under what kind of circumstances does this work properly?

Maybe I should mention that we want to drive a small vehicle with InstaSPIN. Therfore we need some starting torque in order to put it in motion.

Regards

what is your
USER_ADC_FULL_SCALE_CURRENT_A
USER_IQ_FULL_SCALE_CURRENT_A

you can set
USER_MOTOR_MAX_CURRENT to just under 1/2 of USER_ADC_FULL_SCALE_CURRENT_A


"I've been looking for a function to set the IdRef_A but couldn't find it. "
You can see an example of this in proj_lab09 which does field weakening (which is just setting a negative IdRef
CTRL_setId_ref_pu(ctrlHandle, _IQmpy(gMotorVars.IdRef_A, _IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A)));


I'll reply to the rest later...

"However, the motor doesn't move during this process."
In some cases the motor may already be aligned, but in most cases it should move to align, especially if you are putting a bunch of current into it.

"Sometimes is spins slowly with full current and little torque."
What is your speed or torque reference? What is your load?

"We think that, at startup, the current is adjusted just in the wrong electrical axis (the d-axis)"
Without an alignment, you have no idea where the current is oriented with respect to the d-axis.

"Could it be that special motor requirements must be met for the ForceAngle algorithm?"
No, not at all. If you rotate a field, and the IqRef (manual or generated from the output of the speed controller) is large enough, the field should align well enough at some point in the rotation to cause the rotor to accelerate at which time FAST can take over. Assuming you are at a high enough frequency for FAST to provide reliable estimates and your control system is stable / well tuned, it should start-up.

"Based on experiences, what are the average starting torques that can be reached with ForceAngle at startup?"
with a constant load, > 75% torque

"Under what kind of circumstances does this work properly?"
Constant load. With proper settings.

What are you using for your load? Something connected to the motor, or is the motor mounted in a vehicle and you are trying to start?

I might suggest trying to run with proj_lab05a for torque mode. This lets you directly set the peak Iq_Ref required.

as you answer the other questions please drag and drop your user.h file into your reply so I can review.

The values are:

USER_ADC_FULL_SCALE_CURRENT_A = 82.5 amps
USER_IQ_FULL_SCALE_CURRENT_A = 80.0 amps

as can be seen in the user.h I attach to this post (we changed some values due to testing purposes, if there are some values that are inappropriate please let me know)

"you can set
USER_MOTOR_MAX_CURRENT to just under 1/2 of USER_ADC_FULL_SCALE_CURRENT_A "

It looks like it's set to an even higher value than 1/2 - 80 amps. That shouldn't be a problem, should it?

"What is your speed or torque reference? What is your load?"

We've tried out four different scenarios so far. As I mentioned, the motor (actually we have to of them) is mounted to a vehicle and connected to the wheel via gear (gear ratio: 1:3).

In the first case (1), we tried to run the motor with no load (wheel doesn't have connection to the ground) and activate RsRecal + ForceAngle + OffsetRecalc -> Identify -> Run. If current is increased we see the motor spinning slowly (apparently dependent from USER_FORCE_ANGLE_FREQ_Hz). If ForceAngle is disabled, we observe that the direction of rotation is inverted (!) and the speed is slightly higher than with ForceAngle, but still far away from rated speed. If held at zero speed, torque is very small. If motor is given a push, then it sometimes spins up to rated speed, but not always. If current exceeds certain limit while held at zero speed, motor makes loud noise, then torque suddently drops to almost zero (feels like some kind of motor stall). Below this limit, the torque rises quite linear with the current.

Second case (2), similar to first case, but RsRecal disabled. Motor always spins up to rated speed properly. If load it applied at zero speed (e.g. brake with hands), then the torque is significantly higher than in (1). However, still insufficient starting torque for our purpose (scenarios (3) and (4)). ForceAngle has almost no impact on the starting behaviour, in contrast to (1). Current threshold with torque drop, as described in (1), applies to this scenario as well. Torque peak, just before motor stall, is (according to the GUI) 6Nm. Maximum starting torque should be 22Nm (motor datasheet).

Third case (3): Wheel has got connection to the ground, RsRecal + ForceAngle + OffsetRecalc activated. We observe how the motor struggles to move the vehicle, only small movements. ForceAngle makes almost no difference in this scenario. Current threshold again.

Forth case (4): Similar to (3), RsRecal disabled. No namable differences to (3).


"You can see an example of this in proj_lab09 which does field weakening (which is just setting a negative IdRef
CTRL_setId_ref_pu(ctrlHandle, _IQmpy(gMotorVars.IdRef_A, _IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A)));"
"I might suggest trying to run with proj_lab05a for torque mode. This lets you directly set the peak Iq_Ref required."

I will try out these functions as soon as possible and let you know the results.

Regards


---------------------------------------------------------------------------------

user.h:


#define USER_IQ_FULL_SCALE_FREQ_Hz (800.0) // 800 Example with buffer for 8-pole 6 KRPM motor to be run to 10 KRPM with field weakening; Hz =(RPM * Poles) / 120

#define USER_IQ_FULL_SCALE_VOLTAGE_V (48.0) // 24.0 Example for drv8301_revd typical usage and the Anaheim motor

#define USER_ADC_FULL_SCALE_VOLTAGE_V (66.32) // 66.32 drv8301_revd voltage scaling

#define USER_VOLTAGE_SF ((float_t)((USER_ADC_FULL_SCALE_VOLTAGE_V)/(USER_IQ_FULL_SCALE_VOLTAGE_V)))

#define USER_IQ_FULL_SCALE_CURRENT_A (80.0) // 41.25 Example for drv8301_revd typical usage

#define USER_ADC_FULL_SCALE_CURRENT_A (82.5) // 82.5 drv8301_revd current scaling

#define USER_CURRENT_SF ((float_t)((USER_ADC_FULL_SCALE_CURRENT_A)/(USER_IQ_FULL_SCALE_CURRENT_A)))

#define USER_NUM_CURRENT_SENSORS (3) // 3 Preferred setting for best performance across full speed range, allows for 100% duty cycle

#define USER_NUM_VOLTAGE_SENSORS (3) // 3 Required

#define I_A_offset (0.9939797521)
#define I_B_offset (1.014363647)
#define I_C_offset (1.005615234)

#define V_A_offset (0.5020679235)
#define V_B_offset (0.4977650046)
#define V_C_offset (0.4986107945)


//! \brief CLOCKS & TIMERS
// **************************************************************************

#define USER_SYSTEM_FREQ_MHz (90.0)

#define USER_PWM_FREQ_kHz (30.0) //30.0 Example, 8.0 - 30.0 KHz typical; 45-80 KHz may be required for very low inductance, high speed motors

#define USER_MAX_VS_MAG_PU (1.0) // Set to 1.0 if a current reconstruction technique is not used. Look at the module svgen_current in lab10a-x for more info.

#define USER_PWM_PERIOD_usec (1000.0/USER_PWM_FREQ_kHz)

#define USER_ISR_FREQ_Hz ((float_t)USER_PWM_FREQ_kHz * 1000.0 / (float_t)USER_NUM_PWM_TICKS_PER_ISR_TICK)

#define USER_ISR_PERIOD_usec (USER_PWM_PERIOD_usec * (float_t)USER_NUM_PWM_TICKS_PER_ISR_TICK)


//! \brief DECIMATION
// **************************************************************************

#define USER_NUM_PWM_TICKS_PER_ISR_TICK (3)

#define USER_NUM_ISR_TICKS_PER_CTRL_TICK (1) // 2 Example, controller clock rate (CTRL) runs at PWM / 2; ex 30 KHz PWM, 15 KHz control

#define USER_NUM_CTRL_TICKS_PER_CURRENT_TICK (1) // 1 Typical, Forward FOC current controller (Iq/Id/IPARK/SVPWM) runs at same rate as CTRL.

#define USER_NUM_CTRL_TICKS_PER_EST_TICK (1) // 1 Typical, FAST estimator runs at same rate as CTRL;

#define USER_NUM_CTRL_TICKS_PER_SPEED_TICK (15) // 15 Typical to match PWM, ex: 15KHz PWM, controller, and current loop, 1KHz speed loop

#define USER_NUM_CTRL_TICKS_PER_TRAJ_TICK (15) // 15 Typical to match PWM, ex: 10KHz controller & current loop, 1KHz speed loop, 1 KHz Trajectory

#define USER_CTRL_FREQ_Hz (uint_least32_t)(USER_ISR_FREQ_Hz/USER_NUM_ISR_TICKS_PER_CTRL_TICK)

#define USER_EST_FREQ_Hz (uint_least32_t)(USER_CTRL_FREQ_Hz/USER_NUM_CTRL_TICKS_PER_EST_TICK)

#define USER_TRAJ_FREQ_Hz (uint_least32_t)(USER_CTRL_FREQ_Hz/USER_NUM_CTRL_TICKS_PER_TRAJ_TICK)

#define USER_CTRL_PERIOD_usec (USER_ISR_PERIOD_usec * USER_NUM_ISR_TICKS_PER_CTRL_TICK)

#define USER_CTRL_PERIOD_sec ((float_t)USER_CTRL_PERIOD_usec/(float_t)1000000.0)


//! \brief LIMITS

#define USER_MAX_NEGATIVE_ID_REF_CURRENT_A (-0.5 * USER_MOTOR_MAX_CURRENT) // -0.5 * USER_MOTOR_MAX_CURRENT Example, adjust to meet safety needs of your motor

#define USER_ZEROSPEEDLIMIT (1.0 / USER_IQ_FULL_SCALE_FREQ_Hz) // 0.002 pu, 1-5 Hz typical; Hz = USER_ZEROSPEEDLIMIT * USER_IQ_FULL_SCALE_FREQ_Hz

#define USER_FORCE_ANGLE_FREQ_Hz (0.5 * USER_ZEROSPEEDLIMIT * USER_IQ_FULL_SCALE_FREQ_Hz) // 1.0 Typical force angle start-up speed

#define USER_MAX_CURRENT_SLOPE_POWERWARP (5.0*USER_MOTOR_RES_EST_CURRENT/USER_IQ_FULL_SCALE_CURRENT_A/USER_TRAJ_FREQ_Hz) // 0.3*RES_EST_CURRENT / IQ_FULL_SCALE_CURRENT / TRAJ_FREQ Typical to produce 1-sec rampup/down

#define USER_MAX_ACCEL_Hzps (20.0) // 20.0 Default

#define USER_MAX_ACCEL_EST_Hzps (5.0) // 5.0 Default, don't change

#define USER_MAX_CURRENT_SLOPE (USER_MOTOR_RES_EST_CURRENT/USER_IQ_FULL_SCALE_CURRENT_A/USER_TRAJ_FREQ_Hz) // USER_MOTOR_RES_EST_CURRENT/USER_IQ_FULL_SCALE_CURRENT_A/USER_TRAJ_FREQ_Hz Default, don't change

#define USER_IDRATED_FRACTION_FOR_RATED_FLUX (1.0) // 1.0 Default, don't change

#define USER_IDRATED_FRACTION_FOR_L_IDENT (1.0) // 1.0 Default, don't change

#define USER_IDRATED_DELTA (0.00002)

#define USER_SPEEDMAX_FRACTION_FOR_L_IDENT (1.0) // 1.0 Default, don't change

#define USER_FLUX_FRACTION (1.0) // 1.0 Default, don't change

#define USER_POWERWARP_GAIN (1.0) // 1.0 Default, don't change

#define USER_R_OVER_L_EST_FREQ_Hz (300) // 300 Default


//! \brief POLES

#define USER_VOLTAGE_FILTER_POLE_Hz (335.648) // 335.648, value for drv8301_revd hardware

#define USER_VOLTAGE_FILTER_POLE_rps (2.0 * MATH_PI * USER_VOLTAGE_FILTER_POLE_Hz)

#define USER_OFFSET_POLE_rps (20.0) // 20.0 Default, do not change

#define USER_FLUX_POLE_rps (100.0) // 100.0 Default, do not change

#define USER_DIRECTION_POLE_rps (6.0) // 6.0 Default, do not change

#define USER_SPEED_POLE_rps (100.0) // 100.0 Default, do not change

#define USER_DCBUS_POLE_rps (100.0) // 100.0 Default, do not change

#define USER_EST_KAPPAQ (1.5) // 1.5 Default, do not change

// **************************************************************************
// end the defines


//! \brief USER MOTOR & ID SETTINGS
// **************************************************************************

#define our_motor 120

#define USER_MOTOR our_motor //


if (USER_MOTOR == our_motor) // Name must match the motor #define
#define USER_MOTOR_TYPE MOTOR_Type_Pm //
#define USER_MOTOR_NUM_POLE_PAIRS (4)
#define USER_MOTOR_Rr (NULL)
#define USER_MOTOR_Rs (0.3)
#define USER_MOTOR_Ls_d (0.00005)
#define USER_MOTOR_Ls_q (0.00005)
#define USER_MOTOR_RATED_FLUX (0.4)
#define USER_MOTOR_MAGNETIZING_CURRENT (NULL)
#define USER_MOTOR_RES_EST_CURRENT (40.0)
#define USER_MOTOR_IND_EST_CURRENT (-40.0)
#define USER_MOTOR_MAX_CURRENT (80.0)
#define USER_MOTOR_FLUX_EST_FREQ_Hz (60.0)

#else
#error No motor type specified
#endif

Hi again,

I've tried out increasing Id with the function CTRL_setId_ref_pu(ctrlHandle, _IQmpy(gMotorVars.IdRef_A, _IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A))). I replaced the 1.0 by a variable that I can change in the expressions window during program run. Unfortunately, a change of this value didn't have any effect on the starting torque. As far as I know, Id should egenerate a DC current with the potential of aligning the stator to the rotor field. However, when I change Id (by changing the 1.0 in the function), I don't see any change in the current cosumption. What could be the reason for that?

Furthermore, I tested the lab05a - with no success either. What lab05a does is tuning the PI controller. That's something we've tried out before, simply by calling the setKp and setKi functions. We could observe changes in the operating behaviour, e.g. the motor starts more aggressively or runs out smoothly. Apart from that, no change in the starting torque.

Regards

Hello Chris,

we are very happy that we finally managed to get enough starting torque to drive with our vehicle.
Setting a value for IdRef_A indeed did the trick, it is just important for this value to be high enough, in our case something like 10 million. I assume this is due to the ratio _IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A) on which Id is calculated.

The other user.h parameters resulted in further improvement. We will now try to optimize the whole system in order to get the best driving behaviour.

Once again, thank you very much for your time and your help!

Regards, Lukas.

10 Million?
that doesn't make any sense.

CTRL_setId_ref_pu(ctrlHandle, _IQmpy(gMotorVars.IdRef_A, _IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A))).

this Id_ref_pu really shouldn't be > 1.0

It's not the value for Id_Ref_pu that is 10 million, it's the value for gMotorVars.IdRef_A. As I said, I think this is due to the scaling factor _IQ(1.0/USER_IQ_FULL_SCALE_CURRENT_A). When we set this value, we observe an increase in the current consumption (about 1.5 amps) and the wheels move a little bit (probably the alignment process). This supports the motor when Iq_ref is set to reach enough speed so FAST can take over.

Maybe one last thing: Currently, it's only possible to start the motor with very little acceleration, especially below a certain motor speed. If too much Iq_ref is set at almost zero speed, then the motor stalls, rather then being accelerated faster. Is there maybe a way I can optimize the starting acceleration?

Regards

I'm not sure about that one. I believe if you try to accelerate too fast you lose synchronization before FAST can lock on. I believe you will need to keep a slower acceleration until FAST has control.