Identifying PM motors with no rotation with InstaSPIN-FOC
InstaSPIN-FOC requires a few parameters from the motor to run with best performance. The majority of the time this is only done once, and requires the motor to be removed from any mechanical load so it is able to spin freely. A few steps during the identification process require motor rotation in open loop. That is the reason why we require no mechanical load in the motor since it is easy to stall a motor when running in open loop control. When motor can be removed from mechanical load, there is no issue with InstaSPIN-FOC’s identification process, and at the end, motor parameters are available in a watch window for future use.
On the other hand, some applications are, by definition, attached to a mechanical load. Examples of these applications are compressors, some direct drive washing machines, geared motors with sealed enclosures, etc. For those applications, the user requires to run motor identification a little different in order to extract motor parameters with no or minimum motor rotation.
1. Can motor rotate with the attached load?
The first step is to make sure that the motor doesn’t rotate with load. In some cases, the open loop tests can in fact rotate the motor even with some load. If the motor stalls at any point during the identification process, proceed to next step.
2. Run first three steps of identification.
During motor identification, there are three initial steps that don’t require rotation of the shaft. The first one calculates hardware offsets (capture these per the Lab3 instructions and put them in user.h). The second one injects a high frequency current sine wave to identify what we call high frequency resistance (Rhf) and high frequency inductance (Lhf). The third step is to identify the stator resistance (Rs) by injecting a DC current. During this step, take note of the high frequency inductance (Lhf) and stator resistance (Rs). The two required variables in this step are available by using the following function calls from the library:
// get Lhf
gLhf = CTRL_getLhf(ctrlHandle);
// get the stator resistance
gRs = EST_getRs_Ohm(obj->estHandle);
3. Run using motor parameters from user.h
Even though there are ways to calculate the flux of the machine without motor identification this process describes a completely unknown motor. So far we have two parameters we can use, a rough estimate of inductance (Lhf) and an accurate stator resistance (Rs). We are missing one parameter from PMSM motors, the flux of the machine. For this step of the identification process, we will use the two known parameters and a arbitrary value of the flux. Keep in mind that once the motor runs in closed loop, the estimated flux will converge to the actual flux of the machine, so we only need to get the first guess close enough to make it converge to the real value.
Let us take a look at specific defines from user.h
#define USER_MOTOR_NUM_POLE_PAIRS (3)
The number of poles is only important to get the correct RPM reading from the library, but all the library cares about is electrical Hz, and this is not affected by the number of pole pairs. Take your best guess on this parameter. Once the motor is running, this can be changed with the correct number of poles, by commanding a speed reference of 60 RPM, and making sure the motor rotates one revolution in one second.
#define USER_MOTOR_Rs (0.8)
This parameter should be the one obtained in step 2, from variable gRs.
#define USER_MOTOR_Ls_d (0.01)
#define USER_MOTOR_Ls_q (0.01)
For the inductance, we need to use the high frequency inductance obtained in step 2. This is a rough approximation of the inductance of the motor. Having a different inductance compared to the real one limits the performance during high dynamics. For example, if motor needs to run with torque steps, or speed steps, not having the right inductance can be an issue, but having full torque operation with slow dynamics can be done using high frequency inductance instead of the real inductance. So for this step, copy the value obtained from gLhf in both Ls_d and Ls_q.
#define USER_MOTOR_RATED_FLUX (0.5)
Flux is estimated by the libraries, so user needs a value which is close enough to the real one in order to have the real flux of the machine based on the estimator output. Using an arbitrary number can cause some saturation of the estimated flux, since this value is limited internally. This can be easily done by looking at the estimated flux using the following function:
// get the flux
gFlux_VpHz = EST_getFlux_VpHz(obj->estHandle);
If gFlux_VpHz is clamped to a lower than original value set in user.h, decrease the value in half, and if it is clamped to a higher than original value, increase it by doubling the value. Once the motor runs in closed loop with a value on the gFlux_VpHz that varies slightly, then take note of this value and put it back into the USER_MOTOR_RATED_FLUX