Simulink-based floating-point DSP Control Platform Benjamin Rupp1, Howard Lovatt2, Andrea Vezzini1 1
2
Bern University of Applied Science Quellgasse 21 Biel, Switzerland Tel.: +41 / (0) –32 321 63 72 Fax: +41 / (0) – 32321 65 72 E-Mail:
[email protected] URL: http://www.hti-bfh.ch
Commonwealth Scientific and Industrial Research Organisation (CSIRO) Bradfield Road West Lindfield, NSW 2070 Australia Tel.: +61 419 971 263 E-Mail:
[email protected] URL: http://www.csiro.au
Acknowledgements Thanks to Colin Bilson and Vivian D’Offay for help with setting up the motor test rig and thanks to Bruce Kalan and Glen Prout for assistance with the electronics (all from CSIRO).
Keywords «Multilevel converters», «Permanent magnet motor», «Software», «Real time simulation», «DSP», «Converter Control»
Abstract The Simulink-based, floating-point, DSP (Digital Signal Processor) Control Platform is a tool for power electronics and motor drive simulation and for generating embedded code. Performance tests of the system are demonstrated in this paper using a NPC (Neutral Point Clamp) converter and PM (permanent magnet) motor as an example drive system.
Introduction During the last 10 years the number of embedded DSP systems used to control power electronics has greatly increased, moreover, they have changed from fixed-point to floating-point processors recently (thus the decision to target a floating-point DSP). At the beginning of the software- development cycle, a tool for simulating the electronics is most valuable because the electronics are typically developed in parallel and hence are not available for software development (hence the decision to include hardware simulation). In addition to simulating the electronics to enable software development, the simulation also analyses the electronic system and therefore assists with the development of the hardware.
Control Platform The Control Platform is a tool that allows the quick and easy linking of the software development (in Simulink) to the power electronics. It is therefore, a means to simplify the process of hardware and software development for educational purposes or industrial software deployment.
The Control Platform consists of two parts: 1. The hardware platform with the peripheral devices (ADC, PWM, DAC, etc.) and the Simulink library that is used to program the DSP. 2. The blocks in the Simulink library are all generated using the Matlab S-functions and the Target Language Compiler to generate the target files for the floating-point DSP. Besides the Matlab Target Support Package (for Texas Instruments DSPs), which supports on-chip hardware functions, all the on-board, off-chip hardware functions are generated as stand-alone Simulink blocks. For example, code for a four channel DAC is generated from an S-function and makes use of the DSP’s external interface.
Simulation of the hardware One of the first steps in a development process is the simulation of the hardware and the whole system. This is not only important for new development, but is also a vital part in when used as an education system. The simulation of the hardware including the control algorithms, and thereafter comparison to the implementation on an embedded target, will provide a strong understanding of the whole system. It is important in an educational system to encourage the use of an embedded system that is widely used in the industry; the Texas Instruments’ F28335 floating-point processor is amongst the top-sellers in the automotive and related industries. Using such a processor with software that is generated from Simulink, will improve the understanding and the perception of possible problems with such a system. In the following case, the hardware has been simulated in as much detail as possible with PLECS. For this particular hardware, consisting of inverter and motor, both are part of the PLECS library, however both were modified in order to meet the physical requirements. The control of the simulated hardware is performed with the same S-functions that are used to generate the executable C/C++ code on the embedded target. Based on the hardware and S-function simulation, a good prediction about the real hardware behavior can be made. In fact, the results from the simulation and the measured results should be very similar. Such an approach minimizes development time.
Code generation S-functions make use of target functions, which are written in TLC. This hybrid language is superior to C/C++ and can generate custom code for an embedded target. It has to be distinguished between three different types of target functions. First, the system target files are specific for each embedded target and generate source and header files for peripherals. Second, the block target files are implemented in the standard Simulink library, and generates C/C++ code for basic blocks, such as gains or sources. Third, the inlined S-function target files are the custom files for any S-function that needs to generate C/C++ code for an embedded target. With the embedded IDE link any IDE, such as Texas Instruments’ Code Composer Studio can be used to compile and deploy the generated code. It is in the settings of the embedded IDE link that various optimization algorithms for the compilation may be selected.
Fig. 1: Control Platform
Cockpit During the software development, such a system often requires a means to observe certain internal values of the code. These values then need to be displayed to give the user a history of each of these values. Selecting the ‘Log Signal Data’ in the signal properties of each particular signal enables Cockpit logging. The C/C++ code that is generated by Matlab’s Real-time Workshop, gives a structure that contains all the logged data lines from Simulink. This structure is updated with the fundamental frequency, i.e. with 20kHz. An S-Function handles the upload of data to the computer, which is reasonably involved since it has multiple values with different data types and different required transmission rates to the computer. The upload channel is exchangeable, depending on the hardware, as a USB or as a serial link. The host application needs to read the protocol that is used to transmit the data and then to display each of the uploaded values. The Control Platform allows transmitting data in two different ways to the host application. The first method is to upload a down sampled set of data, which is then displayed at real-time. The second method is a burst. In this second case, at every fundamental step time data is sampled and stored in an external flash memory and updated later on. For example, this method allows transmitting transients during a switching cycle. In this case, all data that is conducted per switching cycle is stored in one node of a linear list.
Test System The analysis and performance tests of the system described above have been performed by means of testing with a power electronic test system. This test system consists of a Neutral Point Clamped (NPC) inverter and a permanent magnet (PM) motor. To control the rotor speed of the motor a fieldoriented control scheme and a 3-level Space Vector Modulation scheme were used. The 3-phase NPC inverter consists of twelve power switches and six clamping diodes. The DC link is split into two halves by means of two capacitors; the midpoint is connected to all three legs. With a separate algorithm, this midpoint needs to be stabilized. In detail, without stabilization the inverter in motoring state only sees a drift in the midpoint voltage, while it becomes unstable in the generating state. The stabilization is performed by measuring the midpoint voltage and the DC link voltage. With a PI controller a stabilization value between -1 and 1 is calculated and used in the 3-level SVPWM. Changing from motoring to generating—which is determined by the DC current—changes the sign of the stabilization value. While the current through the diodes and the two outer switches (Sa1 and Sa4) are discontinuous, the current through the two switches in the middle is continuous and during certain intervals equal to the
output current. Hence, the maximum continuous current Id_cont of the diodes and the switches must be able to withstand a maximum current of 5A for the example test setup. The NPC topology offers an advantage of the voltage stress across the devices. As the DC link is split into two sections, only half of the DC link lies across the switches. Thus, VDS_cont of the switches need to be only 25V for the example test setup. Fig. 2: One leg of the 3-phase, 3-level NPC inverter
Comparison between simulations and measurements Every piece of software is written in an S-function that will later communicate in Simulink with other S-functions. For example, a 3-level Space Vector Modulation is written in an S-function and can therefore be tested individually. First, this function is used in the simulation, and the same code is later used on the embedded target. Therefore, testing and comparing the results of each function in the simulation and on the target is very simple. The following Table I demonstrates the comparison between the simulation and the implementation of a single block. In this case, the upper graph shows the duty cycle of the 3-level SVPWM block, while the lower graph shows sector and region of the desired output vector. The left column displays the simulation results, and the right column displays the outputs taken from the implementation code running on the DSP (with motor and power electronics simulated). The implementation results have been conducted by the method that are described above; all the relevant signals are marked as test signals and are then placed in the C structure that is uploaded to the host computer. The interpretation of the data may be changed; in this particular case, the data of these three signals were stored on the host computer and evaluated with Matlab and hence the identical graphical setting to the simulation. This performed test does not give any information about a physical system; in fact, so far the only physical system that is attached to the host computer is the Control Platform with the embedded target (no Power Electronics are connected to the Control Platform).
Table I: Comparison between simulation and implementation of a single block Simulation
Implementation
Besides the block-wise comparison between simulation and implementation, it is also possible to compare the whole system. During the process of software development, the testing of each routine in various test cases is an essential part of the development. It is simpler and more intuitive with the graphical comparison between simulated parts of the software and implemented parts, as described above. Once all the parts and blocks of a whole system are tested individually, they can be used for a bigger project. Furthermore, they are placed in a Simulink library for future quick access in other Power Electronics project. The next step is the simulation of the whole system, in this case a speed controller for a PM motor that is powered by a NPC inverter, while the gate drive is triggered via the Control Platform. In the simulation, the inverter and motor are taken from the PLECS library; while the speed
controller for the motor is based on the S-functions. Fig. 4 gives the theoretical approach for a fieldoriented control that is used in many classical problems of controlling three-phase motors. After the simulation with PLECS, the PLECS block is replaced with a ‘hardware block’. The whole implementation that generates code and deploys C/C++ code to the embedded target is displayed in Fig. 4. The transition from the theoretical interpretation to the real implementation is very short and allows a high degree of reproducibility.
Fig. 3: Theoretical interpretation of the field-oriented control
Fig. 4: Simulink-based implementation of the field-oriented control In this example, the simulation results with PLECS and the measurements of the real implementation are further compared. For this, the accuracy of the physical model is vital, whether the motor is a linear model in the dq-frame, or an accurate, physical model. In addition, parasitic effects from the inverter’s non-linearity have a big effect on the outcome of the comparison physical model to simulation. In the following example, the inverter and motor have been simulated with PLECS, the motor in the dq-frame. The inverter’s parasitic effects have been neglected. This implies that transients do not match in the simulation and on the physical model, while steady-state analysis is more accurate. This, however, is dependent on the used simulation model. With the used, simple model, the simulated rotor speed differs only by 1% from the measured rotor speed at steady state. In fact, with this method a speed of 4000rpm at a switching frequency of 20kHz has been verified.
Fig. 5: Simulation of the 3-phase currents at increase of torque
Fig. 6: Measurement of 3-phase currents at torque increase With an inaccurate physical model, the values from the simulation do not match the measurements very well. As for the used physical model, only a rough estimation of the currents is possible, yet not a thorough analysis. Thus, it is here not sufficient to only simulate without the measurement. The simulation model of the motor, the inverter and the non-linear effects would have to be included for a precise analysis.
Conclusion This paper describes a method of code generation, demonstrated with a neutral point clamped (NPC) inverter and a permanent magnet (PM) motor has been tested and compared to a Simulink simulation. The aim was to use the exact same Simulink blocks for the simulation and for the code generation. The generation, deployment and execution of this code on a Texas Instruments F28335 floating-point have been successfully verified. In addition, determination of rotor speed was first performed as a simulation and then compared to the measurements with the real motor; this has been tested successfully with a difference of 1%. The phase currents was also first simulated and later verified by measurement. For a precise match, the model of the motor and the inverter used is too simple. The use of Simulink and Real-time Workshop to generate C/C++ code and to deploy it on an embedded target offers more flexibility in the software design and a reliable method for testing submodules. Parts of the software can first be tested in the simulation and then directly compared on the embedded target. Furthermore, once the sub-module is generated, it is easy to reuse and assure a high reproducibility.
References [1] Kocalmis A., Sünter S.: Simulation of a Space Vector PWM Controller For A Three-Level Voltage-Fed Inverter Motor Drive. [2] Sayago J.: Three Level Neutral Point Clamped Voltage Source Converter (3L NPCVSC), Lector notes at TU Berlin, Version 6.6.06 [3] Erwan S.: Implementation of a Speed Field Oriented Control of 3-phase PMWM Motor using TMS320F240, Texas Instruments Application Report SPRA588 [4] The Mathworks: Real-time Workshop, Target Language Compiler [5] The Mathworks: Developing S-Functions
[6] Multilevel Inverters: A Survey of Topologies, Controls, andApplications. IEEE Transactions of Industrial Electronics. Vol. 49. No. 4. August 2002 [7] Ashish Bendre et al.„Comparative Evaluation of Modulation Algorithms for Neutral Point Clamped Converters”. IEEE Transactions on Industry Applications, Vol. 41, No. 2, March/April 2005 [8] John Chiasson.„Modelling and High‐Performance Control of Electrical Machines”. IEEE Press Series on Power Engineering. Wiley 2005 [9] Nikola Celanovic, Dushan Boroyevich.„A comprehensive Study of Neutral‐Point Voltage Balancing Problem in Three‐Level Neutral‐Point‐Clamped Voltage Source PWM Inverters”. IEEE Transactions on Power Electronics, Vol. 15, No. 2, March 2000 [10] Shane W. Colton.„Design and Prototyping Methods for Brushless Motors and Motor Control”. Master Thesis, Massachusetts Insitute of Technology, 2010 [11] Dorin O.Neacsu.„Space Vector Modulation—An Introduction”. IECON’01: The 27th Annual Conference of the IEEE Industrial Electronics Society [12] Texas Instruments Europe.„Field Oriented Control of 3 Phase AC Motors”. Literature Number: BPRA073. February 1998
