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
