Develop and Implement Field-Oriented Control for Motor Drives in Simulink - MATLAB & Simulink
Video Player is loading.
Current Time 0:00
Duration 22:07
Loaded: 0.75%
Stream Type LIVE
Remaining Time 22:07
 
1x
  • Chapters
  • descriptions off, selected
  • captions off, selected
  • en (Main), selected
    Video length is 22:07

    Develop and Implement Field-Oriented Control for Motor Drives in Simulink

    Overview

    In this webinar you will learn how to quickly develop and adapt motor control algorithms with the reference examples from Motor Control Blockset. The models provided allow you to verify the algorithms unsing simulation and generate compact and efficient code for a microcontroller. You can implement an automated workflow that updates based on motor parameter inputs, eliminating the need for redeployment. In this session a MathWorks engineer will walk through this workflow for a permanent magnet synchronous motor (PMSM).

    Highlights

    • Model motor and inverter dynamics at different levels of fidelity 
    • Parameterize a PMSM model
    • Design a field-oriented controller, compute gains and verify through closed-loop simulations
    • Deployment through automatic code generation
    • Validate algorithms for different motors without redeployment 

    About the Presenter

    Eva Pelster is a senior application engineer at MathWorks. She holds degree in Aerospace Engineering from the University of Stuttgart. Her area of expertise is Model-Based Design and Simscape for modelling physical systems. Before joining MathWorks, she worked in a technical consulting company. 

    Recorded: 16 May 2024

    Hello, everyone, and welcome to this webinar. My name is Eva. I'm a Senior Application Engineer at MathWorks focusing on model-based design and modeling and simulation of physical systems. And in today's webinar, I will talk about how to implement field-oriented control algorithms in Simulink and how it can support you and speed up your motor control projects.

    So when it comes to developing embedded software for motor control applications, there are typically different challenges depending on your particular role. So an engineer versed in modeling might be wondering how to get the best motor parameters for a particular model. A controls engineer would find it harder to move from control algorithm to an embedded device. An embedded engineer might be struggling with defining the best control gains. And a student or researcher might have to deal with every task and is looking where to start.

    These tasks are, of course, not extensive. So there might be other struggles attached to it. So in the following, I would like to cover how Simulink can help to answer some of those questions and help accelerate a typical motor control development process.

    Before we start, let's have a quick look at what we will be looking at today. We want to talk about how to control brushless motors. For this purpose, we will cover the workflow from estimating motor parameters, calculating control gains, to implementing it and to generating code and deploying it on a dedicated hardware so it can be validated in a closed-loop simulation. This allows us to control the motor speed. We can observe how it follows the demand, as we can see right here.

    Today, we will look at field-oriented control. It is often chosen for its high performance and effectiveness, but its implementation can be complex and challenging.

    So the main points I would like to cover today are how you can create plant models of motor/inverter at the right level of fidelity and how to identify the motor parameters. How you can then move on to designing and simulation of the control algorithms and to fine-tune the controller loop gains. And how to then move on to generation and deployment of embedded code. And to help you in this and to reduce and simplify the development process, we provide libraries and reference examples to the Motor Control Blockset.

    These cover different motor types such as induction motors, permanent magnet synchronous motors, brushless DC motors, and others. And the examples include different algorithms such as field-oriented control, field-weakening control, or model-predictive control.

    So let's start by looking at the basic workflow we'll also use in today's examples. So we work with a plant model consisting of a motor driven by an inverter. And we will need to switch the inverter to control the motor according to our needs. And this is achieved through pulse width modulation.

    And the steps we need to follow are the following. We begin by calibrating the sensors to estimate the motor parameters needed to model the plant. With that, we move to defining the control architecture, fine-tuning the control loop gains. And to implementation by generating code and deployment to the target hardware to drive the PWM pulses. And to support you in getting started, the Motor Control Blockset provides a wide range of examples covering all of these steps.

    So in the first step, we need to know our current and speed and position data to be able to control the motors. So for acquirement, we work with sensors for current speed and so on. And to ensure correctness of the subsequent calculations, the accuracy of the data needs to be ensured. For this, the Motor Control Blockset provides some examples for calibration of ADCs, of position sensors like quadrature encoder, Hall sensor, or the resolver.

    With these position sensors, we begin by spinning the motor in order to get to our initial rotor position. But for example, if this is not feasible, there are also examples of high-frequency injection to allow identification of the initial position without motor rotation.

    After the sensor calibration, we can move to parameter estimation. The motor parameters are needed in order to create accurate plant models. And library blocks and reference examples shipping with the Motor Control Blockset can help with that.

    What is required as input for these examples are basic motor parameters, and with that, instrumented tests can be run to obtain parameters such as data resistance, inductance, and mechanical parameters. And these are available for sensor-based and sensorless setups and help with the execution to simplify the workflow. And this is available across different hardware platforms.

    This demonstration starts with a host model serving as a user interface. The estimation process running from the host model runs tests to identify parameters. And as this is progressing, one parameter after the other is identified.

    So besides parameter estimation using hardware, other techniques are also supported. This includes parameterization from available data sheets. You might also want to import data from FEA tools such as ANSYS Maxwell or JMAG, or use dyno data.

    So with the motor parameters at hand, we can move to using those parameters on plant modeling where the plant in our case consists of motor and inverter. And an important question in any model is determining what levels of detail of modeling should be considered for a specific task. Let's look at the different levels of fidelity using the example of the motor model.

    For example, in the parameter estimation step we just saw, we were provided with parameters for a parameter model. This is an approach which gives a fast-running model and is typically sufficient for control algorithm design.

    For other models-- for example, for control verification, it might be important to include saturation models or to explore the influence of power electronics, a model which includes switching, and more effects might be useful.

    So Motor Control Blockset provides lumped models that support the tasks where a lower fidelity model is needed. And the library is provided by Simscape and Simscape Electrical provide a wider range of fidelity options.

    Here, we are now looking at example displaying the different modeling options for the plant we just discussed. The first variant shows a lumped motor model. Its parameters can be loaded, for example, from the previous estimation step. And the inverter is an average value model.

    The second variant shows a Simscape-based model. This is giving the option to include more detail. There are, for example, different pre-configured switching devices for the inverter model available.

    Now let's look into how the field-oriented control algorithm is built. This is an overview of a motor control block diagram where we differentiate control algorithm and physical system by color. We have already looked into how to implement the physical system. So on the control side, there are a variety of components involved, such as Park and Clarke transformations to convert currents and voltages between reference frames. There is a outer speed control loop and the inner current control loop. And for closed loop control, we also have position or speed as feedback from either sensor decoding or flux observers.

    So to model the structure, again, we can make use of the Motor Control Blockset Library. So the screenshot is one of the reference examples, and the different current control loops are made up out of this library. So the library includes math transforms like Clarke and Park transform, and control reference generators, or lookup table-based current controllers or PI controllers. And all blocks provided support and are optimized for code generation.

    So looking more deeply into the speed-sensing and estimation library, this supports both sensor and sensorless workflows. So for sensor-based control, this includes-- this could include a Hall effect sensor or a quadrature encoder. And for sensorless control, there are also additional options available, such as extended EMF, sliding mode, or flux observer.

    Now after having taken a look at the existing library components, let's look at an actual model to see how this can be implemented. Here, we are looking at one of the reference examples for field-oriented control. In the model top level, we can see subsystems containing different model paths for controls and plant model. And with that exact same model, we can perform both simulation as well as code generation and target hardware deployment at a later stage.

    Looking into the plant model of motor and inverter first, we see the simulation variant active, and this model, as seen earlier, has different fidelity versions of motor and inverter.

    Now opening the subsystem for speed control-- so the outer control loop. The current control loop has hardware inputs. The current control outputs and measurements such as current measurement and quadrature encoder. And the speed measurement. This will also help in understanding the general signal flow and how it switches, for example, from open-loop to closed-loop mode.

    The inner current loop has the Clarke and Park transforms and space vector generator. And this is intended for code generation as well. So here are the peripherals and configurations like the PWM right here.

    So coming back to the top view of the model, one aspect of field-oriented control is that it has an outer speed control loop and an inner current control loop. And the inner current control loop would have faster dynamics than the outer one, meaning both require different update rates. And this can be achieved-- so in this screenshot, we see different colors, and the different colors marked different update rates that are defined through the subsystems.

    So in the last step, we have seen how the algorithms have been implemented. So let's proceed by looking at how the control gains can be identified and tuned. For this, different options are available.

    So we have scripts for empirical calculations provided. So they use motor parameters and basic formulas to calculate suitable gain values. For more fine-tuning, you could, for example, use the FOC Autotune. This helps to achieve a desired bandwidth and phase margin. And you can also use supportive tools such as the PID tuner to view frequency responses and tune accordingly.

    Let's have a look at an example of tuning loop gains. Again, we are working with a reference example for field-oriented control. The speed control is a PI controller block with anti-windup. The speed reference is given as input from the host. And the actual speed is calculated in a previous system in the model based on feedback from the quadrature encoder. The speed control loop executes 10 times slower than the current control loop, which we see right here.

    Here are the signals for phase currents. Motor position and motor speed are used in two PI controllers for direct axis and quadrature axis. These outputs are then converted into three phase voltages, which apply to the motor phases through the PWM generator blocks.

    The subsystem also contains the FOC Autotuner block. Outputs of speed controllers and current controllers are given as input to the block. Additional input signals provide commands to start and stop the autotuning process. Within the block, autotuning goals are defined for target bandwidth and phase margin.

    The block passes out perturbations for the controller that is being tuned. At the end of the perturbation cycle for each of the controllers, the block performs the tuning process. This will compute controller gains. These are then applied to the tuned controller so that when tuning the next controller, optimal gains are being used. This target model is implemented on a Texas Instruments C2000 LaunchPad.

    We start by building the model and deploying it to hardware. Once the deployment is complete, we will kick off the process and use this model to interface the motor. The target model is already running on the hardware connected to a PMSM motor. And the LaunchPad is connected to the computer running the host model.

    Now running the model and starting the motor, we see the motor spinning in steady state. With these sliders, we start the autotuning process. The host model shows tuning to be in progress. The scope right here shows the different perturbation. It starts by tuning the D-axis, then the Q-axis current controller, and in the last step, the speed controller.

    Now the tuning is complete and we can see the newly determined parameters. We will stop and start again to see the new behavior. We can see the response being quicker and is faster to reach the set speed.

    With the complete model now in place, let's have a look at how you can verify the behavior in a closed-loop simulation. So here, we will look at a demonstration showing results for the closed-loop simulation for a plant with different plant model fidelities.

    First, this is simulating the variant that includes switching, and then we run the version with the average value inverter. And we run both options before comparing them. Once this is done, we open the Simulation Data Inspector to explore the results.

    We have, from the top, the speed response, the Iq response, the voltages, the current, as well as the space vector modulation waveforms. The speed feedback shows that tracking of the reference speed value. We can also see the effects of the switching modeling. Here in the Iq plot, the blue line is the output from the average value inverter, the yellow line is from the run of the model with the switching effects. And moving further down in each of the plots, we see there is no difference of significance between the two versions other than the switching giving more detail.

    So up until now, we have looked at the example of a field-oriented control algorithm. So I would like to point out here that there's also a variety of examples provided that cover different techniques and implementations. So some of them are displayed here. For example, sensorless, FRC, or direct torque control. And these examples also cover different motor types. And similar to what we've seen today, they are built to examine closed-loop behavior through simulation, and they all are suitable for code generation.

    Also, more reference examples allow you to explore more advanced techniques. For example, you can look at reinforcement learning, gain scheduling, or model predictive control. And since interest in this is growing, there's also an example that is showing how to partition algorithms for different costs.

    So the previous step was to verify the model in a closed-loop-behaved simulation. We can now deploy the algorithms through code generation,. So all block scenes support automatic floating and fixed-point code generation. And the library is optimized for both C and HDL code generation so you can target different microcontrollers and FPGAs.

    You can also autodeploy on supported hardware kits, but we also provide examples that demonstrate the workflow to target custom hardware. There, you would separate the hardware-independent part of the algorithm, generate code from that, and integrate this. However, if you work with supported hardware, you can also autodeploy and work more seamlessly.

    So here, we see the reference example for a field-oriented control algorithm for Infineon hardware. And you can see the hardware, as well as the motor spinning. Code for this has been automatically generated and deployed. And along with this, you get code generation reports showing you that the code is readable and traceable.

    So before looking at testing the algorithm on hardware, let's see how the reference examples and Motor Control Blockset are typically constructed. As we see here, we typically work with a target and a host model. So the target model is used for code generation and implementation on the target device. And the host model can be seen as a interface to the controller. So with this, you can start and stop the motor, specify input commands, and observe the received signals.

    So with the host model, you validate performance and ensure the expected behavior. So you would automatically generate code, use the host model to debug, and validate the behavior on hardware.

    Let's see how this is working. So again, we are working with the same model as before. After clicking, Build, Deploy, and Start, the code generation starts, and we can see the code being generated. We see the open and readable generation report. And as we are working with supported hardware, it directly gets compiled and deployed.

    So with this host model, we can trigger everything with different elements for user interaction. And with instrumentation, we can, here, for example, see the speed signal tracking correctly. We also could look at other signals of interest. For example, the current waveforms.

    This completes the entire workflow. So you could now go back and reiterate, but what would you do if you want to connect a new motor to the setup? This would require you to repeat the rebuild and flash of every step to account for changes in parameters. So this can be quite time-consuming and repetitive. So with MATLAB R2023b, we can now demonstrate a new workflow that allows the workflow to be adapted to new motors without rebuilding the firmware.

    And before wrapping up, I would also like to highlight how the Motor Control Blockset supports popular embedded targets. Since this is one of the main goals when working with the tool, we aim to support popular microcontroller targets such as TI-2000, Microchip, NXP, STM, and Infineon, but also Speedgoat for real time testing and FPGAs or SoC from Xilinx. So with that, you can develop and deploy algorithms to target microcontrollers and FPGAs.

    So to sum things up, we saw how you can enable Simulink for a motor control workflow. We looked at how to create plant models, design the control algorithm, tune gains, and generate and deploy code. With this, I would like to thank you for attending the webinar. Feel free to reach out to us if you have any questions.

    View more related videos