STM32G474 runaway at high RPMs

[HaraldAnt]

Hi,

I'm struggling with a runaway situation when I try to run my motor at high RPMs.

Here is my setup:

48V power supply, 300A max. The motor has 21 pole pairs. I use the FOC algorithm to drive the motor, sensor-less speed sensing (no hall sensor). I drive the engine with a 20kHz PWM.

I'm able to run the motor up to about 3100RPM. Then it suddenly jumps to maximum power, and I'm unable to control the motor anymore. Setting a new target RPM lower than 3100RPM still makes the motor spin at maximum speed.

When I debugged the system, I see that when we experience the runaway, the FluxWeakening calculations fails, when the measured current is larger than the max current defined in the workbench project. I have defined max current to 300A. The workbench calculates the current conversion factor to 109 as integer, while the actual value should have been 109.22 (as a float). This value is based on the shunt resistor of 0.001ohms and gain of 5.5. However, I changed the current limit values to INT16_MAX instead (for a test), and still the problem exists.

Another theory of what might cause this, is the combination of high RPM and number of pole pairs. To calculate electrical speed by taking RPM value and multiplying with number of pole pairs, I see that at a speed of 31200RPM*21 = 65520. 3121RPM*21 = 65541. If the calculation of measured ERPM is using an unit16 to store the result, it will overflow and suddenly believe the motor is running with ERPM of 5. This will of course make the regulation algorithm apply full power. Reducing the RPM setpoint will not cause the motor to reduce speed as it still assumes the motor is running too slow, hence the runaway. The RPM setpoint of when I experience the runaway is matching the 3120 value.

Based on this, I have two questions:

1. Have I configured the system correctly with regards to shunt resistors, gain value and max current? The system needs to handle up to 65V and 300A. Do I need have some headroom for max current?

2. If my theory of an overflow of ERPM in a 16bit unsigned integer is correct, where is that located in the code? The details of the FOC algorithm is complicated and it's hard for me to pinpoint where exactly the overflow might happen. My hope is that I can implement my own weak function override for this exact calculation to be able to handle the overflow.

Please let me know if anything is unclear or if more system details are required to be able to answer this question.

Best regards,

Harald Antonsen

[STuser2]

The MCSDK code internally converts the RPM into units of Hz. This conversation is available in documentation, you can search in code as well.

[HaraldAnt]

Hi,

Thanks for your answer. I understand that my theory of the problem being the conversion from RPM to something involving the pole pairs was not correct.

However the problem is still there and it seems very much like an overflow occurring when nearing the max power of the system. The input controlling desired RPM is coming from a PWM signal. It's hard to identify the exact desired RPM for when the runaway starts, but it matches the RPM*Pole pairs which might overflow at 3120. Or it could be that it occurs when the RPM is greater than 3276,8. It's hard to pinpoint the exact value.

Any suggestions for what to start looking at to figure where the problem originates and how to debug the system?

As I indicated in the first part of the explanation, we see some rounding errors due to the calculation of max current compared to actual max current. Within the FluxWeakening calculations I see that this results in the system trying to calculate the SQRT of a negative number which results in the output being 0. Could this be causing the runaway? And should I adjust the shunt resistor and gain values to create some headroom for the current measurements?

Br,

Harald Antonsen

[GMA]

Hello @HaraldAnt,

As stated in the Measurement units used by the firmware chapter of the User Manual, electrical speed is defined in tenths of hertz. You can attempt using the hertz speed definition by modifying:

In mc_stm_types.h
/** Revolutions Per Minute: 1 Hz is 60 RPM */
#define U_RPM 60
/** Tenth of Hertz: 1 Hz is 10 01Hz */
#define U_01HZ 10
/** Hertz (Speed in Hz)*/
#define U_1HZ 1 /* (new definition) */
#define SPEED_UNIT U_1HZ /* Speed in Hz (modified definition) */

In drive_parameters.h
#define PID_SPEED_KP_DEFAULT           OriginalVlaue/SPEED_UNIT /* (modified definition) */
#define PID_SPEED_KI_DEFAULT           OriginalVlaue/SPEED_UNIT /* (modified definition) */

[HaraldAnt]

I didn't get changing the Measurement unit to work properly. I didn't have time to debug why it failed.

However, I changed from sensoless CORDIC to sensorless PLL. Now the runaway problem is gone, and the motor works as expected. Seems like there is a bug in the CORDIC implementation that I suspect is triggered by a combination of relative high RPM and a motor with many pole pairs.

In my solution I can run with sensorless PLL without any problems. I was worried that it might cause a too high CPU load, but that is not the case.

Br,

Harald Antonsen