rapid control prototyping for permanent magnet synchronous motor (pmsm) control -凯发k8网页登录

hello, and welcome to this webinar on rapid control prototyping for permanent magnet synchronous motors. my name is chirag patel. i'm an application engineer at mathworks.

if you are currently working on a motor control project or have worked on that in the past, you may agree with me that the first major and exciting milestone of your project is when you successfully spin the motor for the first time. it is also the beginning of a long journey of making small, incremental improvements until you feel safe to connect the motor to its load. nobody spins motors just for fun, unless you are doing it for a webinar.

the second milestone is when you integrate the motor with its load and drive it successfully. that can be, for example, moving your robot arm, driving an electric scooter, or operating a ventilator for the first time. this is certainly the most important milestone for the entire project team, including you, the motor, and inverter control engineers. but this excitement wears off very quickly as we get busy fixing integration and performance issues from previous phases.

we also need to develop detailed diagnostic and fault detection routines, which have very little to do with the actual motor control problems. along the way, we incorporate major hardware and software revisions in preparation for the final product launch.

the goal of this webinar is to demonstrate how mathworks and speedgoat's real-time testing solutions can help you get to the first milestone of spinning the motor as quickly as possible and make subsequent design iterations short and efficient. you will learn how this integrated yet flexible hardware and software programming environment can help you drive product innovation.

using field-oriented control for permanent magnet synchronous motor as an example, i will demonstrate how to transition between desktop simulations and real-time testing with prototype hardware. in the process, i will show you key features of simulink real-time, such as measuring and monitoring signals, tuning control parameters, and logging experimental data, all in real-time.

next, you will learn how to estimate model parameters from experimental data using matlab's data analysis capabilities. test automation is an essential part of real-time testing. i will show you how to automate your test routines and generate test reports using simulink test. while your application or projects will be different, you will be able to apply techniques and features learned from this webinar in your project.

in this webinar, we will not discuss detail of working of permanent magnet synchronous motors or details of field-oriented control algorithms. we will list all the relevant learning resources available on the mathworks website at the end of this presentation. we will also provide you a link from where you can download all the examples used in this webinar.

now let's quickly look at our hardware setup. a host computer with matlab, simulink, simulink real-time, and other required tools is used to design control algorithms and supervisory logic. once we are happy with our initial desktop simulation results, we would like to validate our design on hardware to gain more confidence. so we take our control algorithms and deploy them onto speedgoat real-time target computers using simulink's automatic code generation technology. speedgoat's real-time target computers with io modules allows you to interact with your device under test.

for our example, we are using a speedgoat baseline target computer with multicore cpu and io397 to interface with speedgoat's electric motor control kit. this kit includes a pre-assembled three-phase inverter, three-phase 7-pole pair motor with quadrature encoder for rotor position and velocity feedback.

in this section, we will learn how to spin three-phase pmsm in open-loop mode using just a few simulink blocks and speedgoat hardware. let's assume that you received a hardware development kit with all the key components, such as motor and inverter from your vendor, and you had just enough time to go through the data sheet, getting started documentation, or watch a video. if you're like me, at this point, you are super-excited to wire everything up and spin the motor.

so let's just do that. we will jump into matlab and simulink and spin a three-phase permanent magnet synchronous motor. from the simulink start page, we will select the template for simulink real-time as this option will preconfigure our model with the right solver and coordination settings.

to spin a three-phase motor, we need to apply three-phase sinusoidal voltages at 120-degree phase shift, or 2 pi by 3 in radians. we will attempt to spin the motor at two revolutions per second by multiplying the target frequency with the number of pole pairs of the motor. since we will spin the motor in open-loop mode without the knowledge of phase currents, we need to make sure that the applied voltage is small enough to prevent an over current situation. it is very easy to damage a motor in open-loop mode if there is no provision for over current protection in hardware.

let's add the bias of 0.5 to keep the pwm duty cycle values between 0 and 1. before we connect the signal to pwm block, we need to configure a setup block for the right io module. speedgoat provides a variety of io modules to interact with your hardware. for our setup, we are using io397, which is a configurable fpga module. a bitstream file defines io functionalities and pin mapping of a configurable fpga module. you will get this [inaudible] file from speedgoat as part of your hardware solution.

for example, the bitstream file for io397 implements three channels of pwm output, five general-purpose ios, one channel of quadrature encoder inputs, and four differential analog inputs. these two tables in the documentation defines the pin mapping between a code module channel and physical pin on the terminal board. for example, the high side of the pwm-a a is mapped to pin 3b on the terminal board.

i have already made all the required hardware connections on the speedgoat target computer, inverter, motor, and quadrature encoder. now let's add a pwm generation block. here we define three channel vectors, one for each leg of pwms. now let's configure a few more pwm parameters, such as type of pwm, symmetric or asymmetric, whether pwm b is independent or complement of pwm a, pwm period. select an option to prevent both inverter legs being high at the same time. and when to update pwm generation, and so on.

a very important parameter for pwm is inverter switching frequency. here we are going to assume 20 kilohertz frequency for our inverter. in addition to pwm signals, we also need to provide inverter enable signal via digital output. according to the pin mapping we saw earlier, gpio channel 4 and 5 are connected to the inverter enable and not enable pins via pins 15b and 16b on the terminal board. let's add a digital output block and configure it for channel 4 and 5. we need to enter initial values and reset values to ensure the inverter is disabled when applications start and stop.

next, enter the sample time of 1 kilohertz for digital output block, as it does not need to be updated any faster than that. we will use a constant block and logical not block to feed inputs to these two digital output channels. let's go ahead and take care of data type conversion for these two signals. and add a slider switch to control inverter and connect that to this constant block.

i think we are ready to test this model and spin the motor. since our model is already pre-configured with simulink real-time settings, a real-time tab is available in the tool strip to help us with real-time testing workflow. first, we will select a speedgoat target computer and connect. the run on target button combines the process of code generation and compilation to build a real-time application file, then build this application file onto the target computer.

next, connect real-time application to your simulink model on the host machine. and finally, start the execution on target computer. we also have option to perform all these tasks separately, step by step. let's go ahead and click run on target to start the build process. let me bring camera to see the motor in action. we can see that the motor is not spinning even after the target computer has started the execution. this is expected because we haven't turned the inverter on yet.

so let's turn on the inverter, and here we can see that the motor is slowly spinning at about two revolutions per second. but we don't have any way to measure its speed. now, let's add driver blocks for reading phase current and quadrature encoder pulses and convert them into physical signals. we will run one more test to see if we are reading our feedback signals ok.

this time, let's use simulation data inspectors to monitor signals of interest, such as phase currents and motor velocity. we can modify our scaling values of phase currents in real-time to ensure all phase current values are close to zero when the inverter is switched off and the motor is not spinning.

now, let's turn on the motor. from the camera, we see the motor's spinning. our rotor velocity is -6 point something in radians per second, which is approximately two revolutions per second. and the phase current values are no longer zero. let's turn off the motor and take a closer look at phase current signals. the shape of the phase current is not sinusoidal, but it is expected under normal conditions.

looking at these results, we can say that our calculations for converting raw values to physical units are correct. that's all it takes to spin a three-phase pmsm in open-loop using simulink real-time and speedgoat hardware. it's a small but important milestone in the project.

this milestone gives us a functional, well-integrated rapid prototyping platform that we can use to continue developing closed-loop control algorithms. hopefully, this short demonstration gave you confidence that you can also reach the first milestone of your next project quickly using solutions from mathworks and speedgoat.

we just learned how to spin a motor in open-loop mode. in this section, we will review the implementation of field-oriented control algorithm and test its performance in real-time using speedgoat target computer, power inverter, and a three-phase permanent magnet synchronous motor.

let's start by reviewing our simulink model with foc algorithm already implemented. starting from its inputs and outputs, we have used simulink bus element ports to define the interfaces of the controller logic. userinputs and controllerfeedback bus object pack all input signals to the controller. similarly, motor commands bus packs three pwm output signals and one digital output going onto the power inverter.

mode and rotor velocity signals are purely for debugging purposes. packed in controllerinfo bus, which is not connected to anything else in this example. looking inside the controller model, these first two blocks convert raw sensor signals into physical signals, such as phase current, mechanical rotor position, rotor velocity, and electrical position.

inside the controller_mode subsystem, we have a detailed implementation of different control modes-- disable mode, open-loop velocity control, calibration of encoder offset, and closed-loop velocity control. these control modes are enabled or disabled by the main mode scheduler logic. the state logic is implemented using state flow, as it offers the most intuitive way to design, debug, and test supervising logic, task scheduling, temporal logic, and truth tables.

here we can clearly see the three main operating states-- stand_by, enable_inverter, and error. sub-states within enable_inverter state represent different control modes we saw earlier. the transition between these states and sub-states are regarded by transition conditions based on user input and feedback signals.

additionally, to protect the motor from over current conditions, we have implemented fault detection logic. when over current event is detected, disabled mode is activated and the main mode scheduler will enter the error state. in the open-loop velocity mode, we vary stator voltage and frequency to control the rotor speed without using any feedback from the rotor. this technique can be used to check the integrity of the hardware connections, as we did in the previous section.

the calibrate encoder offset mode calculates the offset between the [? z-axis ?] of the rotor and the encoder index position. the closed-loop foc algorithm needs this value to compute rotor position in [? z-axis ?] [inaudible]. looking into closed loop velocity control mode, it is divided into two cascaded closed loops. the outer loop is for velocity control, which takes command_velocity and feedback rotor_velocity as inputs and generates quadrature current command using pi_controller.

this current control block implements filed-oriented control algorithm. clarke and park transforms are applied to stator currents to derive the d_currents. two pi current controllers are implemented to calculate reference rotor voltages in d and q axis. then, inverse park and inverse clarke transforms are applied to get reference phase voltages in a, b, c reference wave.

we use space_vector_modulation to generate pwm signals, which are then applied to the power inverter. to separate colors in the model, red and green represents two different simple times. the velocity control and mode_schedulers have an update rate of 1 kilohertz, and the control algorithm and other modes updating the values of pwm signals are implemented at a switching frequency of 20 kilohertz. this results in the base sample time of 50 microseconds for the entire model.

to test if the controller logic works on hardware, we need to interface this controller model with the hardware interfaces we created in the previous section. to perform interactive manual testing, we are using dashboard blocks from simulink library. for more systematic testing, we will use signaleditor blocks to alter various test cases. we can use this test harness model to test our controller interactively in real-time.

after completing code generation, compilation, and build process, the real-time application is deployed onto the target machine. upon starting the execution of the test, when we switch the motor on while commanding closed-loop mode, we can see that the rotor speed quickly reaches the target speed with very small overshoot.

if we are not satisfied with the controller performance, or would like to debug its functionality in real-time, we can tune model parameters and observe signals of our interest in real-time while staying in simulink environment. here we can see the response of the controller after the new gain values has been applied. this interactive, real-time testing workflow eliminates the need of generating and maintaining calibration and measurement files.

a well-integrated testing workflow using simulink real-time removes the need for undesired model translation and handover between multiple tools, departments, and engineers, making every design iteration short and efficient.

in the previous section, we learned how to tune motor controller gains interactively. motor control engineers need to have a good estimate of motor parameters such as stage resistance, the [inaudible] of constant, rotator inertia, et cetera to compute controller gains. some of these parameters are often not available in the datasheet, and sometimes motor performance deviates from its datasheet. in this section, we will discuss how to use simulink real-time and its integration with matlab to estimate motor parameters from experimental data.

we will use matlab live script to perform this estimation. first, we load and set up a simulink model with coastdown experiment. using matlab command line interface for simulink real-time, we build the model for speedgoat target, deploy the application, and start the experiment.

in this experiment, we spin the motor to high enough target speed for first two seconds and then disable the inverter. we continue to record data until the rotor comes to a complete halt. we bring experimental data in matlab and plot results. from matlab plot, we select data points from coastdown phase and save as new data in matlab workspace.

during coastdown, the rotor is spinning under its initial load and friction. assuming we have good confidence in the value of rotor inertia, h, we can use this equation and saved data points to perform curve fitting and estimate friction coefficients. to do that, we can either use an interactive app from curve fitting toolbox to fit a custom equation or callfitfunction with the required input argument as shown here.

these are our new estimated values of friction coefficients. we can see from this plot that the fit results and experimental data match very closely. we can further evaluate this fit performance from goodness of fit value. let's update values of friction parameters in our desktop simulation model and compare simulation results with experimental data.

here we can see that we have a very good match for rotor speed during coastdown phase. hence, we use experimental data to improve results of our desktop simulation. we can use the same workflow and technique and create more experiments to estimate other model parameters.

in this section, we learned that applications of rapid control prototyping are not limited to testing logic and tuning controller gains. experimental data can be used to characterize a system under test and improve understanding of the interaction among different components. hopefully, this short exercise showed you how simulink real-time and matlab can help you integrate your design, analysis, and testing workflows.

so far, we learned how to spin the motor in open-loop, test foc algorithm, and analyze experimental data using matlab. we engineers prefer to automate tasks we perform frequently so that we can focus on doing more engineering. this is also true for hardware and software testing of motor control application, where we run certain tests after every software and hardware revision to make sure we did not break anything. we wish to automate this kind of regression testing. in this section, we will learn how to use simulink test, simulink real-time, and speedgoat hardware to automate real-time testing workflow.

you will learn to author test cases and validate test results against baseline criteria and complex logical and temporal requirements. to demonstrate this, let's imagine two test scenarios. in the first scenario, one of the hardware properties, such as friction or inertia, change due to unknown reasons. since the source of the change is not in software logic, the only way to catch this is through hardware testing and compare the test results with baseline test data.

in the previous section, we performed a coastdown test to estimate rotor friction. we will use these test results as our baseline criteria. when we perform our regression test, if the difference in the rotor velocity during coastdown phase is larger than expected tolerance, we can say with a certain degree of confidence that something is not right and we should take a closer look.

the second test case is about over current detection. since this feature is directly related to the safety of our hardware, we want to make sure we don't run into over current situation when we don't expect. and if there is a real over current event, we want to be 100% sure that not only our fault detection logic works but also the controller takes required action in time, for example, shutting down the inverter.

to set up the test automation environment, we will use test manager, a utility from simulink test which helps in creating, managing, and executing test cases and reviewing test results. we have created a test file, which includes our test cases under a container called testsuite. since our tests will execute on speedgoat hardware, we have converted these test cases to a real-time test. this adds new fields, such as an option for loading real-time application and which speedgoat target computer to use to run this test case.

since the coastdown test is only five seconds long, we override the simulation settings for stop time to 5 seconds. we can either define test inputs manually here in the test case or use test scenarios defining the signal editor block inside the test harness model. here we will select closedloop_coastdowntest. next, we select the simulation outputs of our interest. here, we will select rotor velocity, phase currents, and mode as simulation output.

to validate this test run, we need to define pass or fail criteria. our goal is to compare this test run with one we used for motor parameter estimation in the previous section. if rotor velocity from this test run deviates beyond an acceptable tolerance, our estimation for friction coefficients may not be valid anymore. in such a scenario, we declare that the test run has failed. here we will assign the absolute tolerance of three variants per second and a relative tolerance of 2%. this becomes our baseline criteria.

we have used logical and temporal assessment to detect an over current event. we will explore this feature more in the next test case. you can also use matlab functions to define custom criteria. our second test case is designed to purposefully create an over current condition by commanding a large step change in rotor velocity and modifying a default value of saturation calibration. here, in the assessment section, we have altered a temporal assessment from triggerresponse pattern, for which we have an english-like readable description and visual representation.

our assessment criteria reads as, at any point in time, if absolute value of phase current is higher than the current limits of five ampere, and stays higher for at least one millisecond, then starting from that point, with delay of at least two milliseconds, the mode signal should be error.

now let's run this test case. you can alter and execute multiple test cases for software in the loop, processing the loop, and real-time hardware in the loop modes. for real-time test cases, first the model is built and deployed onto the target computer. then the test manager will start execution on target computer and collect all the test data and perform assessments.

now, let's look at our test results. the first coastdown test case failed due to baseline condition. the deviation in rotor velocity is larger than the defined tolerance. this can lead us to further investigate the motor's behavior under normal conditions. under logical and temporal assessment, we can see the test criteria passed, as no over current event occurred.

our second test case passed. we can see phase current was higher than 5 amperes. that led to controller entering error mode within two milliseconds before disabling the rotor. looking at the assessment result, it gives detailed explanation with plots. we can save our test results for future reference and generate a pdf report to share with others in the team.

in this section, we learned to alter and execute real-time test cases and analyze test results all in a single environment. with simulink test, you can re-use your test cases created for desktop simulations and compare results against real-time experiments. this allows us to identify discrepancies early in the development phase. using its integration with simulink real-time, you can automate testing of controller performance, supervisory logic, and hardware io functionalities.

i hope this short demonstration gave you confidence to automate your real-time testing and stay focused on solving key design issues. in this presentation, we did not get into the details of how pmsm or foc algorithm works, and left out details about implementation on production intended hardware.

let's review some of the resources, mathworks and speedgoat how to help you learn more about these topics. the motor control solution page on mathworks website is a great place to start. it list all the resources, including a short video series on pmsm, induction motors, and foc algorithms. there is even a short video on how reinforcement learning can be applied to this application area.

starting from released 2020a, mathworks launched a new product called motor control blockset, which helps you design and implement motor control algorithms. it provides fully assembled reference applications and domain-specific algorithm blocks that generate target-optimized fast and will code. additionally, it provides fully-instrumented models to estimate motor parameters and automatically tune controller parameters using foc autotuner block.

to learn more about speedgoat's hardware solutions, we invite you to visit speedgoat.com. more specifically, explore their programmable fpgas, which can help accelerate execution of controls over rhythms for example, you can deploy field-oriented control algorithms on speedgoat fpga to achieve sample rates even higher than 20 kilohertz. you can even deploy [? simulink ?] plant models on fpgas using mathworks hdl coder to perform hardware-in-the-loop testing for power electronics applications.

and finally, to help you learn these tools, mathworks and speedgoat offer hands-on interactive training. we started this presentation with the goal of helping you get to the first milestone of spinning the motor as quickly as possible and make subsequent design iteration short and efficient.

in the first section, using just a few simulink blocks and speedgoat hardware, we spin a three-phase motor in open-loop control mode. then we use this integrated, rapid control prototyping environment to design and test field-oriented control algorithms and supervisory logic in real-time. this interactive testing environment can be used to tune and calibrate controls parameters and debug logic while staying in simulink environment.

next, we learn how to gain insight from experimental data. the integration of real-time testing framework with matlab's data analysis capabilities help you better understand the system under test. and finally, we learn how to automate real-time testing using simulink test. this workflow is fully integrated with the model verification and validation workflow from mathworks, resulting in a simplified tool chain.

we hope this presentation offered insight into rapid control prototyping of permanent magnet synchronous motors and how mathworks and speedgoat solutions help you make design iterations short and efficient.