INTRODUCTION
In this article we are going to discuss a couple of aspects that you should expect when building complex applications like Motor Control Speed Control of PMSM based on Sensorless methods. As discussed in Module 9: Position Observer (Part 1/2) and Module 9: Position Observer (Part 2/2) there are numerous techniques for estimating the rotor speed and position and one method was chosen to be applied for our use-case.
Now, based on my personal experience with various motor setups and different techniques, I can honestly say that is not always easy to have such a setup working from the first try, and for each application there might be a slightly different approach, extra tuning or perhaps a trick to have it running as per expectations.
As the current publication date of this article proves, I've also run into various issues with this application. Perhaps my initial expectations were high or perhaps I was hopping that someone will glue together modules M8 with M9 and provide a final solution. I'm pleased to see that the articles part of this workshop 3-Phase PMSM Control Workshop with NXP's Model-Based Design Toolbox have thousand of views and lots of comments. But more important is the fact that viewers have started to build their own setups or to participate with articles to extend various functionalities presented in the main articles.
Anyhow, based on your requests passed via this community, personal messages and even direct feedback via FAE/Sales/Marketing (which I would like to thank you all for the interest and valuable feedback) I've decided that is time to put this to an end. Hence, I've started to work again full time on this and now after a couple of iterations, I'm ready to share with you all the final Simulink model that is controlling the S32K144 Development Kit for 3-phase PMSM | NXP in Sensorless Mode directly from MATLAB.
Nonetheless, this article (since it the last in this workshop) is going to be a little bit different than the rest of the ones you got used in this workshop. Instead of focusing how the model is implemented step-by-step and technical aspects (in fact all technicalities have been discussed previously) , I prefer to talk about:
- the approaches I've used to make it work
- what challenges I've faced during development
- things you need to pay attentions when porting your own applications
- suggestions for improvements
How It Works
The zip file that you'll find at the end of this article contains three components:
- PMSM_Sensorless_s32k144.mdl Simulink model developed with MATLAB 2019a. If you need to use an older version of MATLAB, then just open the mdl file as text and edit the third line.
 |
- Sensorless_Params.m Matlab script that computes the parameters for the BackEMF and Tracking Observers discussed in Module 9: Position Observer (Part 1/2) This script is called automatically when the Simulink model is opened in MATLAB.
 |
- FreeMASTER project to control the PMSM behavior, tune and to visualize the parameters and variables
 |
To run the model on the hardware the next steps should be followed:
- Make sure you have the correct SW setup. This model has been developed with Model-Based Design Toolbox for S32K1xx Automotive Version 4.1.0 Type "ver" in the MATLAB prompt to display the version of the toolbox installed
- Make sure the HW is configured correctly to operate in PMSM mode. It is important to verify the J9/J10/J11 position as indicated on the MotorGD shield in order to allow phase current measurements. Also, make sure R72 potentiomenter is set to allow a higher DC current threshold. Read carefully the model description available in the mdl file
- Generate the code for the model and download the code to your target.
- Open FreeMASTER project to control the motor behavior
Implementation Details
The Simulink model for the sensorless speed control of the PMSM is a combination of the model shown in Module 8: Speed Control enhanced with the observers discussed in Module 9: Position Observer (Part 1/2) . The basic control structure is very similar, hence we are not going to repeat our self but instead we shall focus on differences and new features added.
The main control structure with fast and slow control loops is shown in Fig. 1
 |
| Fig. 1: Sensorless Speed Control of PMSM Simulink Model |
The main difference between this model and the one one shown in Fig. 34 within Module 8: Speed Control is the fact that actual motor speed is estimated in the Fast Loop rather than being estimated based on Hall Sensor transitions.
Slow Loop Subsystem
The Slow Loop subsystem has been slightly updated to reflect better the operations that takes place at each 1ms interrupt.
 |
| Fig. 2: Slow Loop Subsystem |
As shown in Fig. 2, the first operation is to deal with the Speed Reference profile during acceleration and deceleration regimes. The next operation is to compute the torque command based on a Speed Controller. In parallel with the speed controller we need to monitor the Speed Reference to select the mode of operation: open loop, tracking mode and closed loop. This information is need to switch from open loop to closed loop operation. The last operation done in Slow Loop is the Alignment procedure which is done only at startup.
In this subsystem the major modifications made compared with previous model in Fig. 33 within Module 8: Speed Control are:
 |
| Fig. 3: Speed Controller Subsystem |
- The Speed_Fbk, estimated by the Tracking Observer needs to be translated from electrical to mechanical units and then filtered with a moving average filter.
- The PI Speed Controller has been enhance to allow an initial value for the integral part accumulator. This is required to have a smoother transitions between open and closed loop.
Fast Loop Subsystem
The fast loop subsystem has been optimized further for getting the best possible performance and to keep some tuning options available. Compared with Fig. 30 in Module 8: Speed Control the new model adds 2 new subsystems highlighted below in blue foreground: Rotor Position and BackEMF Observer
 |
| Fig. 4: Fast Loop Subsystem |
The BackEMF Observer subsystem implements the model shown in Fig. 9 within Module 9: Position Observer (Part 1/2) but this time directly in floating point using the dedicated Automotive Math and Motor Control Library Set | NXP functions: AMCLIB_BemfObsrvDQ and AMCLIB_TrackObsrv
 |
| Fig. 5: Speed and Position Observers |
The parameters for these observers are computed according with the guidelines from the AMMCLIB User Manual.
The other subsystem that has been modified is the Rotor Position, that handles the merging speed/angle between the open loop, tracking and closed loop modes of operation.
 |
| Fig. 6: Speed and Position Observers |
In case of the closed loop operation, due to the delays added by the estimation procedure, we need to compensate for the the rotor phase advance from the moment we read the current/voltages and the moment we are ready to apply the new command voltages. During the computations the rotor will advance with some degrees depending on the commanded speed, hence the new angle needs to be advanced forwards.
Sensorless Run Time
The FreeMASTER project is giving you access to all important parameters and variables for tuning or monitoring actions.
Fig. 7, illustrates a typical startup, followed by an acceleration and deceleration regimes. Throughout these profiles, the Speed Controller manages to keep the motor speed within a decent error envelope of +/- 200 rpm. If better performance is required, then the FreeMASTER can be used to tune the PI controller gains in real time.
 |
| Fig. 7: Control system response at startup and change of speeds |
Further investigations and tuning may be deployed to achieved the best system stability. Fig. 8, shows the BackEMF observer output during startup of PMSM and show fast the estimator can cope with changes in the motor speed commands.
 |
| Fig. 8: Rotor Position and Speed Estimation during startup of PMSM |
Keep in mind that there are multiple parameters that influence the system response, hence you need to have an holistic view of the entire system. Fig. 9 shows how the current controllers behaves during startup (from 5 to 8 sec on the scope) and then during acceleration regime.
 |
| Fig. 9: Flux and Torque current controllers responses |
Some Things to Consider when Porting Applications
Let us presume you have a totally different system (motor and perhaps drive) that you need to configure for running in sensorless mode. If you hope that by simply taking a model like the one shown here, it will work then perhaps you are too optimistic. What are the main steps and procedures to have your system running ?
- The first step (assuming is a new drive and motor) is to check if you can rotate the motor in a simple open loop mode - like the one discussed in Module 5: V/F Scalar Control. You basically connect the motor phases with the power drive and starting from a low voltage command level you check if the motor start spinning. This first step ensure your PWM command sequence are correct.
- The second step is to measure the phase currents. With the motor spinning at low and high rpm in open loop you start to check the ADC measurements as shown in Module 6: Current Sensing (Part 1/2) and Module 6: Current Sensing (Part 2/2) . There is no purpose of moving forward until you manage to read the currents correctly.
- The third step is to tune the Current Controllers making sure the IQ and ID currents can follow your commands. The tuning aspects have been discussed with various occasions. You can compute the gains mathematically and tune the controllers manually, it really does not matter as long as they follow your command. Using the model attached here, you can tune the controllers during the alignment procedure by simply changing the value of the constant in the Align_Sequence State Flow diagram. A larger value will give you enough time during standstill where there is no back-emf to influence the current controller. Remember, that the current controllers shall be always tuned with the rotor at standstill position - typically with current applied in D-axis.
- The fourth step is to tune the observers. Starting from the mathematical equations and your motor parameters you'll get a first set of values. Then you need to verify the estimations. For that you can force the motor to stay in tracking mode by changing the value of the speed limit. In the tracking mode you should compare the estimated speed and electric angle with the ones estimated by the observer. If there are differences between them, try to change the manually the gains of the observers. Based on personal experience the motor electrical parameters like inductance are the ones that influence the most the observer results. So, if our observer fails to produce the correct estimates, then have a look at your electrical parameters first
- The fifth step is to measure the execution of the loops and subsystems. Check how much time does it takes to perform all the computations. The timing might affect the phase advance or even the entire system if the loops starts to overlap.
- The last step is to close the loop. Start with a higher merging speed and then decrease it step by step. If the transition from open to close is not happening correctly, then you need to check the speed controller tuning. Perhaps the transition between the modes creates a disturbance, perhaps the integral part is not at the level it should be from open loop as shown in Fig. 10
 |
| Fig. 10: Transition from open to closed loop |
Once you have the system up and running, then is time for another settings or improvements. Tune the Speed and Current Controllers to deal with the system dynamics and loads.
If you run into issues with this particular sensorless application then perhaps you wish to have a look to other implementations too like the S32K144 Development Kit for 3-phase PMSM | NXP Reference Design.
Improvements Proposals
As it was stated in the beginning of this workshop, the main reason for having these articles is to demonstrate how you can built applications with Model-Based Design Toolbox. These examples should be considered only for teaching aspects and promotion of the toolbox various functionalities. It is not in the scope of these articles to present a state of the art solution but rather to showcase various possibilities that can be address within this space.
In this particular use case, there are a few improvements that could be done to achieve a better control system starting from these examples:
- Optimize the application further by using the dedicated NXP AMMCLIB Controllers instead of the standard ones from Simulink. This will give a bust in performance but it will be harder to tune since the gains will be hard coded into the generated code.
 |
- Replace part of the control loops with dedicated blocks from the AMMCLIB/Advanced Motor Control Library blocks like Current/Speed Loops. This will make your model harder to read but more faster since the number of read/writes for data manipulation will be reduced.
 |
- Change the implementation format from Floating Point (easier for teaching purposes) to a Fixed Point model. This will allow further increase in performance by lowering the time needed for computations. Again AMMCLIB can be used to model such applications.
- Implement a phase advance mechanism that will take into consideration the motor speed. Now, that is a fixed value that covers the entire range of operation of a particular motor. For a more generic implementation, that should consider the speed range and the amount of time needed for computation in fast loop.
- Consider both clock wise and counter clock wise directions. Currently the model implements a single direction assuming the sensorless applications are mainly used for pumps/fans and such type of devices that do not require reversals.
- Another area suitable for improvements is the one dealing with application failures and monitoring. Using finite state machines like the one presented here Model Based Design Approach to Motor Control with S32K144 - part No.1 you can build a complex application on top of existing model to deal with real life scenarios. Currently the model attached do not contains any kind of failure modes for the application like what need to be done in case the sensorless estimation is crashing. These kind of feature is the responsibility of the engineers that design the application to deal with.
- Modelling improvements is another area that could potentially improve the user experience. Integrating Simscape - MATLAB & Simulink into the model will help to compare the simulations against the real hardware implementation. Since not all the users might own such licenses we tried to stay apart of such models or at least we tried to build our simplified plants as shown in Module 5: V/F Scalar Control and Module 9: Position Observer (Part 1/2)
If you have other ideas for improvements, let us know as comments below. We look forward to see more applications implemented on top of Model-Based Design Toolbox | NXP and show cased here in this community.
Good luck!
Update revisions:
May 06, 2020
- Added the model to work with Model-Based Design Toolbox for MPC57xx Automotive Version 3.2.0 .
Hi hayaoki7,
The detected speed - can't be changed. It is a value computed by the observer at each 100ms.
The motor speed can be changed via:
- Option one - Click on the Speed Widget in the FreeMASTER
- Option two - use the Variable Watch window
In general all the variables can be converted from read-only to read/write from Variable/Modifying tab
In this example there is no hall sensor needed - the rotor angle estimation requires only the i_a/i_b phase currents and control voltages u_alpha and u_beta. In M8 we use the hall sensor to estimate the speed because the motor do not have an encoder. If you have motor with any other type of sensor mounted - then it would be much more easier and more robust to build a motor control application.
Best regards,
Daniel
