|Electric Motors in Automotive – Speed Control Is Everywhere|
Permanent-magnet synchronous motors (PMSM) are widely used for many automotive applications due to their high torque, high power density and high efficiency. In a typical modern car there are numerous functionalities that are driven by PMSM type of motors and most of these functionalities need to operate at various speed levels that must be controlled precisely. Besides car industry, there are many other areas of industrial control that require the motor speed control capabilities to ensure a proper system operation: just think about a bottling factory conveyor belt system, or an airport walkway, or why not an car assembly line. All these would not be possible without an appropriate way to control various motors speed.
This example uses the HALL Sensors to implement a simple position estimator. The usage of HALL Sensors should not be mistaken with 6-step commutation technique used to control the BLDC. In this case the HALL sensors are used just for estimation and correction of the electric angle used for FOC
|Fig. 3: Field Oriented Control - Block diagram|
The TORQUE CONTROL operation is very important at this time because it will allows us to perform various tests with the speed and position estimator prior of closing the speed control loop.
The second global variable, MODE is generated internally by the software algorithm and it is used to control the motor startup process and zero crossing during change of rotation direction. Since we are dealing with an estimator we need to cope with low speed ranges and 0 crossing when changing the motor speeds from clockwise (CW) to counter clockwise (CCW) directions. This variable has three possible values (see Fig. 27 for a graphical representation):
We will discuss about the importance of these modes in the next workshop modules where we will focus on SENSORLESS control system.
|Fig. 4: Closed Loops Speed Control - Block diagram|
|Fig. 5: DevKit MotorGD pins used for Hall sensors|
|Fig. 6: S32K144 Evaluation Board MCU Signal Assignment|
|Fig. 7: Simulink model for reading the Hall Sensors with S32K14x MCU|
On S32K14x Evaluation Board these signals are inverted. To get the same logic value as the true Hall input we need to invert the acquired value in software.
|Fig. 8: HALL sensors signals|
Based on these considerations, it is easy to understand that for each 360 electrical degrees (THETA) we will have six Hall sensor transitions as shown in Fig. 9. These six transitions give us the possibility to measure the position of the PMSM rotor with an accuracy of 60 electrical degrees for any speed range.
|Fig. 9: Hall sensors transitions versus one complete electrical rotation (-pi: pi) radians|
Since we know how many radians are between two consecutive Hall sensors transitions, we can easily compute the speed of the motor as:
Therefore, reading the value of a timer/counter on each hall transition should give us an accurate information about how fast the rotor is spinning, right ?
In Fig. 10 we have captured such use-case. On the top of the figure we have the Hall sensors variation captured as a Hall sSector representation in decimal form and on the bottom we have the timer values for each Hall sensors transitions. In this capture you can see that even if the motor is commanded to spin in torque control at constant speed the time counted between consecutive hall transitions presents a variation.
|Fig. 10: Hall sector change timings|
This variation is mainly cause by the undefined installation error of the three hall sensors which are not at a perfect 120 electrical degrees apart of each other. If we would try to build a speed estimator based on this approach we will have to deal with a lot of variations that are induced by this poor mechanical hall installation that might vary from one motor to the other.
In Fig.11 is shown the speed estimation results in case of counting the time between each hall sensors transitions. In this case the motor was commanded to spin in Torque Control at a constant 1000 rpm demanded speed using open loop control. As you can see the estimated speed (SPEED_FBK blue) has a large variation around the set point.
|Fig. 11: Speed estimation by counting the time between each hall sensor transitions|
Such speed estimation signal may be filtered out but to smooth down such large variations it might required a large sample data as history and that may introduce phase delays in the final closed loop control system that may create control system instability. Therefore it must be a different way - a better one!
After analyzing the system response we have reached to the conclusion that would be better to count the time between a single hall transitions over 360 electrical degrees. This way we can get rid of additional sources of errors that might affect the speed estimator like:
The new Simulink model that is supposed to handle this scenario is shown in Fig. 12. Each time there is transition from HIGH to LOW on the HALL C (is has been selected since from PCB point of view it is all the time routed to the MCU) the new estimated speed is getting computed.
The formula implemented in the Compute Estimated Speed block is based on:
Using this approach we can estimate the actual motor speed far more cleaner that before. Fig. 13 shows the estimation results in the same conditions as the one from Fig. 11.
|Fig. 13: Speed estimation by counting the time between one Hall signal transitions over 360 electrical degrees|
The dynamic results of the Speed Estimator are shown in Fig. 14 and Fig. 15 for startup and change of direction with zero crossing.
|Fig. 14: Top: Reference (green) vs Estimated (red) Speeds, Bottom: Speed error between the reference and estimated speeds during motor startup|
As can be seen, we have an expected larger error at startup until the motor starts to move constantly. Then during acceleration and steady state regime the error between the reference and estimated values are quite small +/-20 rpm which I think is quite good for this kind of approach relative to solution costs.
|Fig. 15: Top: Reference (green) vs Estimated (red) Speeds, Bottom: Speed error between the reference and estimated speeds during change of direction with zero crossing|
At this point I think we can say the speed estimator based on a single Hall sensor signal transitions is accurate enough for our purpose. The next question that rise now is: how to obtain the electrical angle that is used for FOC transformations that ultimately controls the rotor position?
For FOC, the 60 electrical degrees resolution is not good enough to control the rotor position using sinusoidal control approuch. We will need to find a way to improve this accuracy in order to be able to reuse the Hall sensor information for PMSM sinusoidal control.
With the PMSM rotating at a constant speed like Fig. 16 shows, the Hall sensors values change regularly.
Fig. 16: Hall sensors changing at constant speed - comparison between hall change (black), hall sector (blue)
and open loop electric angle (red)
Any changes of Hall sensors value could be captured by the MCU via dedicated GPIO Interrupts and then the software application could reads the three Hall sensors values to judge in which section edge the rotor is. The Simulink model that implements the Hall sensors change capture is shown in Fig. 17. As can be seen, dedicated GPIO ISR blocks are used to trigger a subsystem execution each time the Hall sensor changes its state LOW to HIGH or HIGH to LOW.
|Fig. 17: Simulink model for capturing the Hall sensors transitions|
For instance, when the MCU captures a Hall sensor value changing from 110 to 010 then it is easy to know that θ is equal with 60 electrical degrees apart of phase A magnetic axis. The whole 360 electrical degrees spectrum can be divided into six areas, each one spreading over 60 electrical degrees. This concept was discussed in Module 4: Space Vector Modulation during Space Vector Modulation.
|Fig. 18: Hall sensors states vs. PMSM rotor angle|
Using only the six Hall sensors transitions we can build a simple model to estimate the rotor position with a resolution of 60 electrical degrees as shown in Fig. 19.
|Fig. 19: Coarse estimated rotor position (green) vs. Ideal rotor position (red) when using Hall sensors transitions|
But how to estimate the rotor angle within these six sections is an important problem which can be solved by using the estimated speed. Looking at the Fig. 18, we can see that the rotor position can be approximated quite precisely in case we know how fast the PMSM rotates.
In FOC algorithm, the rotary speed of last 360 electrical degrees section is used to predict the rotor position for the next 60 electrical degrees section now which of course implies that the speed used until next Hall changes is not the real speed at the present moment.
The predicted rotor angle may contains errors if the motor speed is not constant, (e.g.: the PMSM is accelerating or decelerating). So the electrical angle estimation result may have some deformity when the PMSM speed is fluctuating.
The coarse estimated rotor position shown in green within Fig. 19, can be easily computed with a simple SWITCH in Simulink as shown in Fig. 20.
|Fig. 20: Simulink model used to compute the coarse rotor position with 60 electrical degrees resolution based on Hall sensors transitions|
This is a simple implementation that assumes a specific Hall switching pattern as shown in Fig. 19. For any other motor this part of the model must be updated.
The position angle increment computation is shown in Fig. 12 and is computed in the same time with the estimated speed as a simple multiplication with a scaling factor from rpm to rad/s and of course the sampling time of the fast loop
where the Hall transitions timer is incremented.
Applying all these knowledge we can compute a more accurate rotor position based on actual Hall sensors transitions and the estimated speed of the PMSM. Fig. 21 shows a comparison between the ideal rotor position (THETA) and the predicted position (THETA_CORRECTED) based on the algorithm discussed above.
Fig. 21: PMSM rotor position comparison:
(red) represents the ideal rotor position which is imposed in open loop Torque Control
(green) represents the coarse estimated rotor position with a 60 electrical degrees resolution based on Hall sensors transitions
(blue) represents the rotor predicted position based on Eq. 3 that includes the speed prediction
If we check the Fig. 21, we can spot a few things that needs to be addressed:
The first issue can be easily addressed in software and Fig. 22 shows how to deal with such aspects in Simulink.
|Fig. 22: Bounding the estimated rotor position to (-pi:pi) radians using standard Simulink blocks|
Regarding the second issue, the things are a bit more complicated than they seems and to explain it, we need to have a deeper understanding of the PMSM internals: phase voltage, back-emf and Hall sensor mounting. Lets discuss all these in the next section.
One of the most important control system design challenges is the phase lag between the commanded phase voltage impose via SVM and the resultant sine-wave phase current for that naturally occurs in an PMSM/BLDC motor. The PMSM can operate satisfactorily, but the overall efficiency will be reduced (as shown in Fig. 39), defeating much of the purpose of implementing a FOC control scheme that by definition should drive the motor at its optimal operating point.
The source of this inefficiency is not the phase lag between motor phase voltage and phase which some might think but rather the phase lag between phase current and the induced back-EMF voltage as it is shown in Fig. 23.
The Hall sensors are mounted in such way that when the induced back-EMF reaches its maximum value a Hall transition will happen. In this case, since we can measure directly the back-EMF with our model, it is safe to assume that back-EMF is synchronized with Hall transitions.
|Fig. 23: Phase lag between phase voltage (U_A_Ref) and phase current (Ia) and the Hall A transitions that are synchronized with back-EMF in phase A|
In order to eliminate this lag between the back-EMF (Hall A) and the phase current (Ia) we need to introduce a phase-angle advance to the sinusoidal drive current to ensure its peak coincides with that of the back EMF (Hall transition). This phase-angle advance can be easily deducted based on the FreeMASTER recorded captures and in my case it seems to be 1/6 from a Hall half period (the dotted areas) which can be translated in a pi/6 radians or 30 electrical degrees.
In general, the phase-angle advance is typically set to increase linearly with the phase command voltage, which determines the motor speed. Since our scope is to introduce general concepts and show how to implement them with Simulink rather than building a dedicated speed control system targeted for a particular motor - in this module we are going to use a constant electrical angle offset to compensate for this lag and drive the motor to its peak efficiency within a specific speed range.
Depending on your application you might need to consider this aspect.
The compensation of the electrical angle (Fig. 24) for clockwise and counter clockwise direction is implemented on the slow control loop and uses constant offsets that are added to the corrected electrical angle as shown in Fig. 21.
|Fig. 24: Electric angle offset calculation for phase lag compensation|
By using all these tricks we should be able to predict the rotor position quite accurately in both clockwise or counter clockwise directions as shown in Fig. 25 and Fig. 26.
|Fig. 25: PMSM rotor position corrected (blue) with phase-angle advance of 30 electrical degree for clockwise direction|
|Fig. 26: PMSM rotor position corrected (blue) with phase-angle advance of 30 electrical degree for counter clockwise direction|
Fig. 26 shows a 180 degrees angle shift between the coarse angle obtained from Hall sensors (green) and the electrical angle corrected due to the mechanism used for calculations. To keep the same algorithm implementation for both directions, the corrected angle is shifted in software with (pi-pi/6) radians
As can be seen in both Fig. 25 & 26, there is a small jitter present on the predicted rotor position which is due to keeping the same angle increment over 360 electrical degrees and small variations with the estimated speed, but that should not be an issue for the control system.
Overall, taking into account the accuracy of predictions for both speed and position on one hand side and the cost of such basic type of sensors we can conclude at this point that this kind of method is quite suitable for motor control applications.
In industry there are two main techniques to cope with such situations:
Depending on your application requirements you may choose between one or the other method. For this module we are going to implement the Force Startup since it is more common and less complex than the BLDC Startup. If you are interested in BLDC control theory you may want to check BLDC Motor Control with Model Based Design
Fig. 27 shows the speed range partitioning for the Force Startup approach.The speed limits are available for changing in the Model Workspace associated with the Simulink Model File.
|Fig. 27: Force Startup speed zones and speed limits between transitions|
The Simulink model is built to take into consideration these transitions and change the Speed Feedback (SPEED_FBK) and Electric Angle (THETA) used for FOC according with the speed area in which the motor operates. In order to accommodate this mechanism some changes had to be made to both SLOW and FAST LOOP Subsystems.
|Fig. 30: FAST CONTROL LOOP Simulink Model: Note the Rotor Position subsystem that computes the angle needed for PARK transformations.|
Fig. 31: Rotor Position Conditioning for addressing all application use-cases:
- Speed Control vs. Torque Control
- Open Loop vs. Closed Loop
- Normal Operations vs. Rotor Alignment
The actual speed control is implemented as normal in the slow loop using the Simulink model shown in Fig. 32.
|Fig. 32: SLOW LOOP CONTROL Simulink Model|
The speed is regulated with the help of standard parallel form PI controller that is setting the motor torque reference IQ_REF based on the error between the SPEED_REF computed as the output of the RAMP block and the actual motor speed estimated from HALL C sensor transitions (SPEED_FBK). The controller output is limited in order to avoid a high current thru the motor and anti-windup based on clamping strategy is enabled.
|Fig. 33: PI Speed Controller implementation with additional signal conditioning for handling startup and zero crossing|
The final model used for closed loop speed control is shown in Fig. 34. This model is more or less universal and represent the basic form of any speed control system based on Field Oriented Control and cascaded loops for dealing with electrical and mechanical parts of the PMSM or any motor in general.
|Fig. 34: Simulink model of the Closed Loop Speed Control system for PMSM with S32K14x MCU|
|Fig. 35: System startup: TOP- reference vs. actual motor speed [rpm], MIDDLE - speed error [rpm], BOTTOM - PI Speed Controller output torque reference [Amps]|
Fig. 36: Field Oriented Control algorithm responses for the profile shown in Fig. 36
- TOP 2 graphs: Q Axis Torque Controller inputs (IQ_REF, IQ) and output voltage command (UQ_REF)
- BOTTOM 2 graphs: D Axis Flux Controller inputs (ID_REF, ID) and output voltage command (UD_REF)
Fig. 36, demonstrates how the current controllers operates under acceleration and deceleration regimes. Note how the D-axis current controller is adjusting the control voltage in D-axis to compensate for additional back-EMF in oder to keep a zero magnetization current ID.
Fig. 37, shows the system response during startup and change of direction. Note how the handover is done between closed loop and open loop control strategies and how the rotor stops for a moment when changing directions.
|Fig. 37: Motor Startup and Zero Crossing (same quantities as in Fig. 35)|
If all the results above were perform under no load conditions, the Fig. 38, shows the system response under the effect of disturbances. The motor is kept at a constant 2000 rpm speed level when suddenly random load torque are applied on the rotor shaft. The Speed Controller reacts very quickly increasing the demanded torque to compensate for the lost in speed.
|Fig. 38: Speed Controller perturbation rejection|
Another interesting aspect that relates to FOC efficiency is shown in Fig. 39, where is presented the effect of phase angle compensation offset over the motor torque. By changing the value of the compensation, the motor is still able to maintain the desired speed profile within the same limits but this time with a larger current needed for producing the appropriate torque to spin the rotor. This demonstrate how important is the rotor position in FOC. A small 30 degrees deviations and the torque demanded is almost 3 times higher to maintaining the same conditions.
Fig. 39: Phase angle compensation offset influence over FOC efficiency for the same speed profile and load:
(a) pi/6 offset (as computed from Fig. 23 results), torque current is ~0.75Amps
(b) arbitrary 15 degrees off the optimal point, torque current is ~1.2Amps
(c) arbitrary 30 degrees off the optimal point, torque current is ~2.5Amps
We hope you have found plenty of useful information in this module that will allow you to build your own speed control system.
March 19, 2018
Before using the new models make sure you apply all the hot-patches from here: HotFix: MBD Toolbox 2018.R1 for S32K
I have a same problem.
I downloaded M8 zip file and execute, but the motor is not spinning.
The LED is keep BLUE after blinking many times with GREEN color.
I am using same demo kit and LINIX motor.
How did you solve this problem.
I would like to know how did you solve this problem.
Below is my FreeMaster images
Hi Pony Huang,
I see that the UQREF is saturated at 0.4. Are you sure you are using the last model. Can you try by downloading once again the model attached?
Also, before starting the motor, can you try with a lower speed - let say 250rpm. Does is spin ?