Emulation of a Low Power Wind Turbine using a DC Motor

James Derricott & Bryan Hanson

Abstract

This thesis, Emulation of a Low Power Wind Turbine with a DC Motor, presents an emulation system designed to recreate the behaviour of a 300W wind turbine with zero steady state error. The system uses a DC motor as the prime moved to replicated the behaviour of the wind turbine shaft and is controlled using a parallel simulation in Matlab/Simulink, This simulation takes speed as input from the DC drive, calculates the tip speed ratio and uses this to look up a value for the torque coecient which it uses to calculate the torque required to be written to the DC drive. To eliminate steady state error voltage and current outputs are fed back into a characterised generator model and the torque present on the generator can be directly calculated, which is compared with the required torque giving rise to an error. The error is then fed through a PI controller and written to the drive. To speed the control up the main torque calculation system is implemented as a feed forward path, while the PI operating on the error signal forms the standard control path. Under steady state wind conditions the emulation system matches the emulated wind turbine with enough accuracy to achieve the original aim of the emulation system and is a good representation of a low power wind turbine.

ii

Acknowledgments

Thank you to A/Prof Grahame Holmes, our supervisor in this project.

To Matthew Sacher, for his work in modeling the wind turbine generator and his help in testing the wind turbine.

To Monash wind tunnel, for the use of their wind tunnels and helping set them up for our use.

Thank you to Martin from the electrical workshop for helping in the construction of the aerofoil test set.

And a very special thank you to Dr. Peter Freere, our mentor and supervisor for this project, who deserves more than the mere mention here. He has been so helpful and generous to us with his time and knowledge, and has made a big dierence in our project.

Thank you Peter.

The authors James Derricott and Bryan Hanson can be contacted further at jamesderricott@yahoo.com and bhan.francis@gmail.com respectively.

iii

Glossary of terms

Aerofoil Blade of the turbine which generated the lift force required to produce the turbine force, or torque, which turns the blades of the turbine. Cp The Power Coecient denes the energy the turbine has extracted from the wind, and it is denoted by Cp, and is dened as the ratio of the power extracted from the air to the power available in the air This power coecient will vary based on something called the Tip Speed Ratio (see below). TSR Tip Speed Ratio, () - Ratio of the speed of the rotor tip speed to the speed of the incoming wind stream. The Cp curve will be a maximum for some unique tip speed ratio Cq Torque coecient, found by dividing the Cp by the TSR CT Thrust coecient TT Torque developed by the rotor HAWT Horizontal Axis Wind Turbine VAWT Vertical Axis Wind Turbine E Kinetic Energy Density of air PT Turbine Power A Swept area of the rotor blades of the wind turbine v Volume V Velocity of incoming stream of air (or wind velocity) (m/s) R Radius of swept area (m) N Rotational speed of the rotor (revolutions per second) 1.21 kg/m3 is used in the system

iv

Contents
1 Abstract 2 Acknowledgments 3 Glossary of terms 4 Introduction 5 Wind Power 5.1 Outline . . . . . . . . . . . . . . 5.2 Wind energy . . . . . . . . . . . 5.3 Wind energy conversion systems 5.4 WECS Emulation . . . . . . . . . 5.5 Summary . . . . . . . . . . . . . 6 Generator Modeling 7 Aerofoil characteristics 7.1 Overview . . . . . . . . . 7.2 Tip loss . . . . . . . . . . 7.3 Cp curve comparison 7.4 Summary . . . . . . . . . 8 Steady State Testing 8.1 Overview . . . . . . 8.2 Wind tunnel . . . . . 8.3 Cp curve derivation 8.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ii iii iv 1 2 2 2 2 4 5 6 8 8 9 12 14 16 16 16 17 19 20 20 20 21 22 22 24 25 26 27 28 31 32 34 34 35 36 39 40

9 Emulation System 9.1 Overview . . . . . . . . . . . . . . . . 9.2 Hardware Description . . . . . . . . . 9.3 Emulation software . . . . . . . . . . . 9.3.1 Modularity . . . . . . . . . . . 9.3.2 Interface . . . . . . . . . . . . . 9.3.3 Execution . . . . . . . . . . . . 9.3.4 Schematic . . . . . . . . . . . . 9.4 Serial communication . . . . . . . . . . 9.4.1 RS-232 . . . . . . . . . . . . . 9.4.2 Mentor II Communications . . 9.4.3 Tektronix TPS 2024 . . . . . . 9.4.4 GW Instek GDX-820C . . . . . 9.5 Compensation . . . . . . . . . . . . . . 9.5.1 Static Friction Compensation . 9.5.2 Running Torque Compensation 9.5.3 Active Compensation . . . . . 9.6 Inertia . . . . . . . . . . . . . . . . . . 9.7 Summary . . . . . . . . . . . . . . . .

10 System performance 10.1 Outline . . . . . . . . . . 10.2 Steady State performance 10.3 Dynamic performance . . 10.4 Summary . . . . . . . . . 11 Further work 12 Conclusion 13 Appendices 13.1 Appendix 13.2 Appendix 13.3 Appendix 13.4 Appendix 13.5 Appendix 13.6 Appendix 13.7 Appendix 13.8 Appendix

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

42 42 42 49 51 52 53

A: Startup and Initialisation Procedures . . B: Aerofoil Testing Code . . . . . . . . . . . C: DC drive serial communication code . . . D: Oscilloscope Serial Communication Code E: Torque mode.m . . . . . . . . . . . . . . F: Startup sim.m . . . . . . . . . . . . . . . G: shutdown sim.m . . . . . . . . . . . . . . H: Accompanying CD directory listing . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

55 56 61 65 68 69 71 73 74

List of Figures
1 2 3 4 5 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 A small HAWT. (1) . . . . . . . . . . . . . . . . . . . . . Emulation system from (2) . . . . . . . . . . . . . . . . . Generator equivalent circuit . . . . . . . . . . . . . . . . . Star Equivalent Generator Model . . . . . . . . . . . . . . Aerofoil Testing Rig . . . . . . . . . . . . . . . . . . . . . Lift vs angle with endplates . . . . . . . . . . . . . . . . . Drag vs angle with no endplates . . . . . . . . . . . . . . Drag vs angle with endplates . . . . . . . . . . . . . . . . Cp-TSR curve WITH endplates . . . . . . . . . . . . . . . Cp-TSR curve WITHOUT endplates . . . . . . . . . . . . Cp-TSR curve comparison . . . . . . . . . . . . . . . . . . Turbine in Monash University wind tunnel . . . . . . . . . Experimental Cp-TSR Curve . . . . . . . . . . . . . . . . Emulation System Setup . . . . . . . . . . . . . . . . . . . Measurements & plotting capabilities . . . . . . . . . . . . Live CQ - curve plotting . . . . . . . . . . . . . . . . . . . Simulation model . . . . . . . . . . . . . . . . . . . . . . . Core turbine simulation . . . . . . . . . . . . . . . . . . . Example BCC calculation, Courtesy Control Techniques . Mentor II DC drive front panel . . . . . . . . . . . . . . . Mentor II serial cable connections. Control Techniques. . Tektronix TPS 2024 4 channel digital storage oscilloscope GDS-820C 2 channel digital storage oscilloscope . . . . . . GDS-820C serial cable connections. Courtesy GW Instek. Mentor II remote inputs . . . . . . . . . . . . . . . . . . . Feedback oscilloscopes . . . . . . . . . . . . . . . . . . . . Modied control loop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 6 7 9 10 10 11 13 13 14 16 18 20 23 24 25 26 28 29 31 31 33 34 36 37 38

vi

29 30 31 32 33 34 35 36 37

Power vs. Loading condition . . . . . . . Voltage vs. Generator power . . . . . . . Current vs. Generator power . . . . . . . Electrical frequency vs. Generator power . Tip speed ratio vs. Generator power . . . RPM vs Generator power . . . . . . . . . Torque vs. Generator power . . . . . . . . Step response to a load increase . . . . . . Step response to a load decrease . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

43 44 45 46 47 48 49 50 50

vii

Introduction

Wind generation systems are a growing area of interest, increasingly in lowpower applications for rural areas. A critical aspect to the success of such systems is the development of low-cost power electronic interface converters. Developing innovative solutions in this area requires a rigorous testing procedure, a testing procedure which can be controlled in a laboratory condition without the unpredictable eects of wind.

The motivation for this project is to create an emulation system that as closely as possible replicates the behaviour of a wind turbine in steady state conditions, which will allow the testing of power electronic devices designed to maximise the turbine power output. This emulation system removes the unpredictability that goes with testing a turbine under real wind conditions and also removes the need for large expensive and time consuming wind tunnel testing, and if the behaviour of the emulator can be made dyanamic enough it would actually be better for testing power maximizers then the wind tunnel, as it would not only work in steady state conditions, but in cases of varying wind as you would see in a real installed turbine.

This thesis presents an emulation system that seeks to satisfy the above aim of replicating the behaviour of a real wind turbine for the purposes of creating a convenient test set to be used to test wind turbine power maximizers. The consruction of each part of the emulation system is outlines in this document as well a performance review of how well it actually emulated a turbine.

5
5.1

Wind Power
Outline

In this section, the characteristics of wind pertinent to energy conversion will be presented; followed by an introduction to wind energy conversion systems. The equations governing such systems, their components and performance characteristics will be described in detail.

5.2

Wind energy

The natural motion of air in the atmosphere, wind, is caused by pressure dierences across the surface of the earth do to the uneven heating via solar radiation (3, pp. 22). From studies of uid mechanics, this ow of air can be analyzed as mass ow with kinetic energy given by:
dm dt Ek

Pk

= AU 1 = 2 mv 2 1 = 2 AU 3

(1)

Where A is the area of the incident air stream, U and the velocity and density of the ow respectively. Generally, A, the stream area of interest is taken as the area swept by the rotor of a wind energy conversion system (WECS). Such systems convert the linear momentum of the air stream into a rotation of the WECS rotor, with a maximum possible eciency of 59.26%, referred to as Betz limit. The derivation of this value is beyond the scope of this introduction, however it may be found in (3, pp. 87). Furthermore, it can be observed from 1 that the available power in the wind increases at the cube of the air velocity, and from a substitution of A for the area of disk: 1 R2 U 3 (2) 2 That a twofold increase in the radius if a WECS blade geometry results in a fourfold increase in captured energy. Pk =

5.3

Wind energy conversion systems

To date, there have been a variety of WECS designs; however by far the most popular and widely used is the horizontal axis wind turbine (HAWT). As made clear in the Introduction, the design of interest is the low-cost, low-power HAWT design common in rural and urban applications. Such systems are becoming increasingly popular due to increased concern over greenhouse gas emissions, and consist of following 4 main components: Rotor assembly This consists of the blades of the turbine, along with the hub; upon which the blades are mounted. The performance of a wind turbine is greatly aected by blade geometry, and in many designs, this component is also the most expensive part of the turbine unit. Drive train Connecting the rotor to the generator is the drive train. In larger wind turbine systems, the drive train includes gearing to increase the speed of rotation from the rotor into the generator. Small turbines do not have this feature, the drive train for these systems is simply a connecting shaft. 2

Generator The generator converts the mechanical rotation of the drive train into electricity. Small turbine generators are commonly of the 3-phase, permanent magnet type; however other generator types have been used. Controller To protect the system, in addition to converting the output of the generator to domestic voltages, a power electronic interface converter is necessary. As noted, the performance of a turbine is greatly aected by geometry. Characterizing this performance is commonly done with a CP - curve; a plot of power coecient to the tip speed ratio of the blades. The power coecient CP denotes the eciency of the blades in extracting the power in the wind, whilst the tip speed ratio (TSR) is the ratio of the speed of the blade tips to the air stream. The relationship is found as follows: PT 2PT = Pk AV 3

CP =

(3)

Thus, CP is the fraction of power that is transferred from the wind to the turbine blades (4). As previously mentioned, the theoretical limit for this is approximately 59.3%. This term can be modied to then nd the torque in Nm of the rotor that the wind induces (3, pp.164): Q CQ
1 = CQ 2 R3 U 2 CP =

(4)

Where CQ is the torque in Nm developed by the rotor, and calculated as per 8. Of particular interest is the low power systems outlined in the introduction. These systems have a much wider application, from powering remote emergency telephones to powering outback water pumps. As such, technology improvements in these systems can lead to a large increase in renewable electricity generation.

Figure 1: A small HAWT. (1)

An example of these systems is shown above, and are commonly used to charge batteries. Such a system allows electricity to be drawn without the turbine operating, and are generally small enough for roof mounting.

5.4

WECS Emulation

Prior systems that attempt to replicate these low power systems do so in a more specic way. An example of these systems, (2) and (5), can be found to use lower rated DC motor sets and dedicated computer hardware systems. Such systems maintain only a limited control over the system and are unable to provide the operator with a highly exible environment to rapidly iterate the emulation system over a variety of user dened operations.

Figure 2: Emulation system from (2) One such system is shown above, and limits the operator of the system to feeding in a wind prole before execution. Such a system does not allow the user to control the wind speed directly, or view various system variables on the simulation PC as the execution platform is a separate Daq board. It therefore desirable to nd a more general solution to the emulation of such systems in order to increase the scope of research that may be carried out on such systems.

5.5

Summary

This section has presented a brief overview into the basic equations that govern the performance of a wind turbine. The conversion of kinetic energy to rotor energy was explored and previous simulation systems were presented. The systems that have been used to replicate these turbines was explored and their shortfalls mentioned. Finally, the general solution to emulating these systems is introduced as a focus for the remaining sections.

Generator Modeling
James Derricott

The following subsection describes the work done by Matthew Sacher(6) from his undergraduate thesis in modeling the 300W watt turbine generator. Matthews work is referred to heavily throughout this following subsection. The reason to characterise the generator is to provide an ability to predict the output voltage, current and power of the generator for any given speed. In order to be able to predict the output, Matthew has used the RPM, the open circuit voltage, and the internal resistance of the generator. To test whether the model was correct Matthew used a 2.2 load. This can be seen by the following circuit representation, utilising the internal resistance R and internal inductance L of the generator, the derivation of which will be shown later in this section.

Figure 3: Generator equivalent circuit Using the following equation the output voltage and current can be predicted within 40% at very low speeds and to within 10% at higher speeds.

|V t| =

2 RT

E RT RL + (L)2

2 RT

E L RL + (L)2

(5)

Above is the voltage at the load terminals. A similar expression gives the current through the load; |It| = E RT 2 + (L)2 RT
2

E L 2 + (L)2 RT

(6)

In the following equation the following terms are used; E = Generator back-emf = Angular Speed = 2 (RP M/15) 6

Rg = Internal resistance of the generator RL = Load resistance RT Total Resistance = Rg + RL L = Internal inductance of the generator

Figure 4: Star Equivalent Generator Model In order to calculate the internal resistance of the generator a series of known currents are fed into the generator and the resistance is then calculated using Ohms Law, while a simple digital multimeter can be used at zero current. Then using a star equivalent model of the generator the internal resistance then become half of the measured line to line resistance, giving a value of 0.8485. To calculate the internal inductance of the generator, the inductance of each phase was rst found by manually turning the shaft in 20deg increments to determine the minimum and maximum values of inductance of each phase. As before using a star equivalent model of the generator means the internal inductance is then halved to give a value of 2.358mH. A model of the 300W wind turbine generator was developed that gave the ability to predict the output power (and hence the torque) of the generator. This characterisation of the generator assisted in not only the calculation of the CP curve with data measured in the Monash University wind tunnel, but also later in the emulation systems feedback to enable calculation and comparison of the output torque with the required torque.

Aerofoil characteristics
James Derricott

7.1

Overview

When an aerofoil is being subjected to a stream of air, be it on an airplane, or wind turbine or any other application, the aerofoil produces a lift force as a result of dierential pressures on the aerofoil sections. This dierential pressure is a result of the air stream moving over and below the blade at dierent velocities thanks to the shape of the blade. In the case of a wind turbine this lift force produces a torque which turns the blade. The production of lift force from moving air over the aerofoil works best when the air stream is a continuous uniform ow. This uniformity is disrupted at the tip of the aerofoil, when instead of owing smoothly over and below the aerofoil section it swirls out from the tip. This reduces the eciency of the aerofoil as most lift and power is produced closest to the tip. In order to determine if this tip loss is signicant for this turbine the aerofoil blade was tested using a specially conducted test rig in a 1 by 1 meter wind tunnel at Monash University. As well as investigating tip loss, the aim was to also produced a CP curve that could be compared to the curve determined in the wind tunnel.

7.2

Tip loss

In this subsection a comparison is presented between the lift forces on an aerofoil section with and without end eects plates. The end eect is a term used to describe the loss of eciency that an aerofoil section experiences near its end tips. This eect is cause by the air swirling around the tip in a non-uniform fashion, thereby reducing the eectiveness of the tip of the blade - a section of the aerofoil with which most power is produced.

Figure 5: Aerofoil Testing Rig The apparatus used to test this eect can be seen in the above gure. By adding plates of aluminum to the ends of the aerofoil it in aect forces the air to ow past the tip in a uniform fashion, thereby eliminating the swirling around the tip that is characteristic of the end eect, and assumably making the whole section more ecient in producing lift.

Figure 7: Lift vs angle with endplates In the above gures, we can see the dierence in lift force experienced by the aerofoil is impacted by the presence of the end eects plates, which help to eliminate the loss of power from the swirling aects of wind at the blade tips. It can be seen that in having the end plates present on the aerofoil section, that the lift improves and hence the power and eciency of the blade will also improve.

Figure 8: Drag vs angle with no endplates

10

Figure 9: Drag vs angle with endplates Having the end eects plates present on the aerofoil appears to increase the drag slightly at higher angles, meaning a slight reduction in blade performance may result.

11

7.3

The Lift and Angle data of the aerofoil taken from the wind tunnel measurements can be used to calculate the CP curve which can be compared to the curve obtained by testing the whole turbine in the wind tunnel. The algorithm for doing so is explained below, but for the full code it is suggested the reader look at Appendix B: Aerofoil Testing Code. The testing of the aerofoil was done at 13.4m/s wind speed, while the testing of the wind turbine was done at 9m/s. There was no time to complete further testing of the aerofoil at 9m/s, but there should not be an issue with comparing the two Cp curves as the wind speed should have no eect on the nal result. The Cp data is calculated over a range of shaft speed values, from 300 to 1000RPM. The blade is divided up into 100 blade elements, and a tangential and effective velocity is calculated for each blade element, which then enables the calculation of each blade elements angle with respect to the wind. Each blade element produces a dierent amount of lift depending on its angle. To nd the lift that each blade element produces, the angle of that blade element is compared with the angles of the aerofoil measured in the wind tunnel. Each angle of the blade elements gives a value of lift calculated at that same angle in the wind tunnel (although scaled by 100 blade elements). The torque for each element is then found by multiplying that lift by the length of the element, and then summing them up to give the total torque for the aerofoil section. This total torque multiplied by the number of blades gives the torque produced by the complete rotor. The power is then the total torque for the rotor multiplied by the angular speed . The CP is then calculated using; CP = And then the TSR; = P
1 2 3 2 R V

Cp curve comparison

(7)

R Vwind

(8)

Over the range 300 to 1000rpm these values can then be plotted to give the CP curve shown below.

12

Figure 10: Cp-TSR curve WITH endplates This comparison can be done with or without endplates. In practice it would seem intuitive that only one end plates would be necessary to correctly calculate the CP-TSR curve.

Figure 11: Cp-TSR curve WITHOUT endplates These curves approximate the Cp-TSR curve measured for the wind turbine

13

well up until a TSR of 6, at which the curve is expected to reach its maximum and start to come back down. However this does not happen and an explanation for this is not available at this time.

Figure 12: Cp-TSR curve comparison The above gure shows a comparison between the curves obtained for the aerofoil with and without endplates (blue and green respectively) and between the curve obtained from experimental data in the wind turbine. It is immediately obvious that the curve for the aerofoil is no longer valid after a TSR of 6, but before that oers a comparable result.

7.4

Summary

Using data obtained from testing a 300W wind turbine in a large wind tunnel, a Cp-TSR curve was found. Then using the same aerofoil blades in a smaller wind tunnel, lift forces on the blade were measured through various angles. These were measured with and without aluminum plates on the ends of the blade to determine the eects of tip loss on performance. The data obtained from these tests was used to determine the theoretical Cp-TSR curve which is directly comparable with the curve obtained in the large wind tunnel. This comparison yielded results which were accurate up until a TSR of 6, after which the results diverged. No explanation is given for this eect at this stage and would be a subject of further investigation if time would allow. However below a TSR of 6 the comparison results are considered valid and demonstrate the relationship of the blade aerodynamics to the Cp-TSR curve. 14

15

Steady State Testing

James Derricott

8.1

Overview

In the following section the reader is introduced to the topic of steady state testing, which is necessary to determine the performance of the wind turbine under various conditions, such as dierent wind and loading conditions. Testing of the turbine in the wind tunnel, combined with a model of the turbine generator, yields a result for the Cp-TSR curve, which can then be used in the implementation of the emulation system.

8.2

Wind tunnel

In order to determine the steady state performance that the emulation system required, it was rst necessary to determine our benchmark performance - i.e the steady state performance of the wind turbine that was to be emulated. The wind turbine and Cp data used int his section was made available thanks to Peter Freere of the Monash University Power Electronics Group.

Figure 13: Turbine in Monash University wind tunnel To facilitate this requirement a large wind tunnel of dimensions 6 by 4 meters was used, in which was placed the low-power (300W) turbine and then run at numerous steady state wind speeds and under various loading conditions. The

16

gure above shows the testing of the turbine in the Monash University Wind Tunnel.

The wind turbine was tested under both AC and DC loading conditions. For AC loading conditions the generator output was connected to two three phase load banks connected in delta, in order to provide a high loading condition as necessary. The DC loading was done by rst rectifying the AC output and then using a 12V battery as the load, which replicates the real intended loading for this type of wind turbine.

Using the results obtained from each type of loading, including variations in direction of wind and the wind speed, CP curves can and were produced. The method for doing so is explained in the next subsection.

8.3

Cp curve derivation

This following subsection outlines how the CP T SR curve was obtained using the results of the wind tunnel testing.

The equation to obtain the Cp-TSR curve from the wind tunnel data is shown below; P (9) CP = 1 2 3 2 R V Where: R is the blade length, or Radius of the swept area, V is the velocity of the incoming wind stream, P is the Power. The tip speed ratio () which the CP is compared with is given simply as; = 2 R RP M/60 V (10)

Which can be seen is the ratio of the speed of the tip to the speed of the incoming wind.

In applying the above CP formula, two dierent forms for the term Power can be used. Either the power can be obtained using the AC output voltage and current from the generator, or by using Matthew Sachers model of the wind turbine generator to give a value for Blade Torque which is then used to

17

calculate the Blade Power as follows; P = BladeT orque 2 RP M/60 The Blade Torque is found using the generator model equation below; BladeT orque = Where PRC refers to P + Rectier Loss + Converter loss, the power output in addition to the losses in the rectier and converter, which are only applicable the the load is being rectied and fed into a DC load rather than an AC load. P RC = 3 VACrms IACrms 2 + VDC IDC + IDC 1.5 2 + 0.1 IDC 3 (13) (11)

Where; 3 VACrms IACrms VDC IDC 3 is the power output of the generator, IDC 1.5 2 is the Rectier Loss, and
2 0.1 IDC

is the Converter Loss.

Figure 14: Experimental Cp-TSR Curve

18

The above CP curve shows that the 300W wind turbine tested is not terribly ecient, with the maximum CP of 0.22 being well below the Betz limit of 0.59

8.4

Summary

The past section has outlined the use of the Monash University wind tunnel in testing the steady state behaviors of a 300W wind turbine under dierent wind speed and dierent loading conditions including three phase AC loading and DC loading with a rectier and battery arrangement. The data measured from the wind tunnel was used with the generator model to nd the Cp-TSR curve, which was used directly in the emulation system which is discussed later and also used as a comparison with the data collected from the aerofoil testing to make a comparison between the Cp-TSR curves from the previous section.

19

9
9.1

Emulation System
Overview

The following section introduces the emulation system as a cohesive unit, in addition to describing the design choices and specications of individual components. Limitations of the current system will be also be detailed; including an overview of modications the authors feel would enhance the system.

9.2

Hardware Description
James Derricott

In order to emulation the way a real wind turbine behaves it is necessary to replicate the behavior of the wind turbines shaft to act as a real shaft would as it was being driven by the wind. This section describes the hardware used to achieve this.

Figure 15: Emulation System Setup The above gure shows both the real wind turbine system and above it the emulation system, whos main objective is the re-create the same voltages, currents, and frequency output as the real turbine under the same operating conditions, such as wind speed and loading. AS can be seen above, the physical emulation systems consists of a number of important components, namely the generator, the DC motor and the DC drive, all controlled via a PC running a parallel simulation in Simulink.

20

The PC interfaces with the Mentor II DC drive via an RS232 serial cable. This drive accepts a torque command from the PC, and also sends the current speed of the DC motor back to the PC, which is then used to calculate the Tip Speed Ratio. The drive uses this torque command to control the DC motor. The DC motor used is a separately excited DC machine rated at 30kW, which is being used as the prime mover for the emulation system, which means that it is providing the torque and power to rotate the shaft that would have otherwise have been provided by the wind. In order to write torque commands to the drive, a commanded torque in Nm must rst be scaled to a value from 0 to 100% of full-rated torque that the drive is capable of applying. To measure this scaling factor a lebow torque transducer was used as well as a signal conditioner calibrated to match. A known value of torque was applied to the shaft of the DC motor using a cantilever. A value of torque (in % full-rated) was then written to the drive until an equilibrium was established, thus giving a scaling factor between real torque in Nm and % full-rated. The DC motor is then connected to a permanent magnet induction generator rated at 300W continuous output power, which was taken directly out of the real wind turbine that this project is emulating. After the generator the three phase output can be used with dierent loads, as a three phase output or rectied and used to charge a 12V battery. The output voltage and current from the generator is also used by the system as a feedback in order to check how well the system has responded to the input commands. In order to read the voltage and current into the PC, two separate digital oscilloscopes are used, each with the ability to communicate to the PC via a serial cable. This provides a closed-loop system which can eliminate steady state errors in the emulation of the turbine.

9.3

Emulation software
Bryan Hanson

The software platform selected for the simulation is The Mathworks product MATLAB, in addition to the Simulink modeling package. MATLAB, a numerical computing environment, was selected as it presented signicant benets over the more traditional microprocessor approach; as a more general solution to wind turbine emulation was sought. The main features required in the emulation system were as follows: Modularity Wind turbine design is an innovative eld, with new designs introduced on a regular basis. Testing these designs for regional wind performance or specic conditions such as gusting currently requires the purchase and test of the units in large wind tunnels. The ability to experiment with dierent designs on the test system without requiring fundamental modications to the solution would allow for new technology in wind turbines to be

21

developed in a more timely manner. Radical blade designs may also be tested without the cost of physical construction. User interface Operator control for the system was desired to be as straightforward as possible, requiring only a minimum of instruction to use. The same applies for system modication; various wind regimes and turbine characteristics can be altered or replaced by the operator with ease. This allows the system to be used by a greater number of people, including those without available resources to test turbine designs in a wind tunnel. Time critical Hardware-in-the-loop simulation requires timely calculations, the system needs to react in a realistic manner to load variations applied by the turbine controller. Under steady state conditions, this requirement may be relaxed; controller performance is generally calculated as an overall eciency irrespective of dynamic behavior. All of these requirements can be met by MATLAB, in addition to oering the facility of porting the simulation system to a variety of dierent hardware platforms and architectures. Each of these features will be covered in detail in the following sections, followed by an analysis of the realized simulation. 9.3.1 Modularity

The simulation platform as a whole exists as a series of functions programmed in the MATLAB programming language, called m-les. These les contain the commands used by the simulation to initialize itself and communicate with the system hardware. As such, the system lends itself easily to modication, and can quickly be ported to work with system hardware other than that dened above. In addition to this, characteristics of the turbine to be modeled are contained within separate les loaded by the initialization script. This design allows turbine characteristics to be modied quickly, as the variables are not encoded into the simulation itself. This includes the CQ - curve and various properties of the turbine and simulated environment including blade radius and air density. The user may also easily extend the scope of the simulation platform, such as integrating the CQ - curve as the output of a series of aerofoil geometry analysis scripts. This allows the simulation platform to perform a more general emulation role, capable of not replicating the performance of existing designs but simulating the performance of a design that does not physically exist.

9.3.2

Interface

The simulation user interface has been built using the MATLAB GUI layout editor Guide. This allows user friendly interfaces to be designed to operate the simulation using familiar controls such as check boxes, sliders and pull-down menus. Due to the tight integration with the MATLAB suite, these user interfaces may display or control any simulation variables used by the simulation model, in addition to modifying a subset of these during execution.

22

The nature of this design means that the trained user may design their own layout, displaying and modifying only the values that interest them during the simulation. This extends to the modication of data logging, as the use may choose to record any time varying values, such as generator voltage, to a separate le to be exported into a variety of formats or plotted against other variables such as wind speed.

Figure 16: Measurements & plotting capabilities As such, the simulation environment may be tailored to the users requirements quickly and easily, to facilitate focus on either specic aspects of the system such as the controller algorithm behavior in over speed conditions or as general as the steady state eciency of the rectication stage of the power electronic interface converter. The default user interface, whilst containing a variety of interface controls, includes a novel display of the CQ - curve. This curve updated during simulation execution and shows the position of the system on the curve in red. This custom function is a convenient method for the operator to visually inspect the current eciency of the system and the eect of load variations from the power interface converter. Naturally, this plotting function may be modied to display the CP -, or any other values if the operator so desires.

23

Figure 17: Live CQ - curve plotting 9.3.3 Execution

As the simulation system is not a fully developed product, the current execution of the system limits it turbine simulation behavior to steady state conditions. This is in part due to the currently used method of simulation execution, a non-deterministic soft real-time execution on the Microsoft Windows XP operating system on a consumer PC. This platform is not ideally suited to real-time capabilities and thus prevents the system from executing at a simulation speed 1 to 1 with reality. This results in behavior that does not match that of a real turbine with regard to the timing of events. An example of this phenomenon is the time taken for the simulation to begin from a standstill to reach steady state if an eective step change of wind speed is applied. The time for this to occur will not necessarily be the same as that of the real turbine; and while it may be possible to tune the simulation execution parameters to ensure this occurs, it may not hold for dierent values of step changes. However, the simulation has the potential to execute in real time through a variety of methods. The rst and most convenient is the use of the real-time target for Windows, a product from The Mathworks that enables Simulink to operate in real time. In addition to this, the simulation may be ported to a platform where kernel mode execution will result in deterministic operation; such as a Real-Time Operating System (RTOS), through the use of MATLABs Real-Time Workshop. This results in the Simulink model being compiled into C code for portability to a wide range of platforms and architectures, including embedded systems.

24

9.3.4

Schematic

As previously mentioned, the simulation itself is programmed in the block diagramming environment of Simulink, connected to MATLAB and the system hardware using script les. This programming paradigm allows the simulation to be graphically built from a series of blocks that perform a specic task, which will each be introduced and explained below.

Figure 18: Simulation model The above image shows the full simulation. It may be viewed in detail under appendix 13.8. Below shows the core simulation section of the model:

25

Figure 19: Core turbine simulation Beginning from left to right, the simulation executes sequentially, from source to sink block. This process is iterated over the desired time period using the operator dened time step. The process that occurs in a single time step occurs as follows: Beginning the process, the simulation retrieves the shaft speed of the generator from the DC drive over the serial communications link. This, coupled with the user dened wind speed input to the system at the current time step is used to calculate the tip speed ratio from 10: R U

(14)

CQ Once the current TSR is calculated, the corresponding CQ value is found using a lookup table. This table is user dened and may be modied by the operator to simulate dierent turbines. CQ lookup is performed using interpolation and so the curve may be dened using a loose set of points. Aerodynamic torque The simulation then continues by calculating the aerodynamic torque of the blades exerted on the generator given the current conditions. This calculation, 4, as follows:
1 Q = CQ 2 R3 U 2

concludes the calculations related to the theoretical performance of the turbine, sans inertia (see 9.6). Remaining blocks are concerned with closed loop control of the generator torque, detailed in 9.5.3 and components of the user interface, such as the live CQ - curve plotting mentioned previously in 9.3.2.

9.4

Serial communication
Bryan Hanson

26

Communication with the hardware components previously introduced in ?? occurs over RS-232 serial channels. Each peripheral involved in direct communication with the simulation PC occupies a D-subminiature 9 pin COM port with a cable to suit its unique requirements. In addition to this, each device requires a separate series of commands to operate, each of which will be discussed on a device by device basis below, following an introduction into the RS-232 communication standard.

9.4.1

RS-232

The RS-232 serial communication standard denes the transfer of binary data between 2 devices. In the original standard, the intended topography of the network at the time were end instruments connected via a modem. This resulted in the standard dening communication between Data Terminal Equipment (DTE) end instruments and Data Circuit-terminating Equipment (DCE) modems. In addition to this, communication between devices was coordinated with ow control signals, so that devices would not attempt to transfer binary data at the same time. RS-232 communication between devices used for the simulation system are arranged for direct communication to the simulation PC, that is DTE-DTE, and do not use ow control to coordinate the transfer of information between them. Each of the devices additionally denes the wiring of the cables that connect them to the simulation PC, however the transmit and receive lines remain the same for all devices. This permits the use of MATLABs standard function calls to create a serial object that may be written and read to using fprintf() and fscanf(), native functions that can be used to directly read and write parameters to each device individually. Each of the devices may be individually addressed for these operations as the read and write functions are passed the serial object to interact with, of which any number of serial objects can be created. During execution of the simulation, where read-writes are performed many times a second, it was deemed that error checking would not be performed. This approach has proved to be working arrangement, and only one issue with this has arisen. As the reads and writes are blind, if the serial operation returns an error, such as a timeout occurring because a message terminator was not received, the simulation will halt. This behavior is highly undesirable, and mostly unpredictable, occurring mainly with the Mentor drive under high CPU loads. With regard to the speed of the RS-232 communications links, it was decided that 9600 Baud would be sucient to transmit the short messages between the dierent peripherals. If future expansion of the system results in inter-device communications exceeding this speed, the RS-232 standard denes speeds that are considerably greater than that chosen, and the serial object creation section of the initialization script may be modied to reect this change. The parameters of interest for each peripheral follows below, including the nature of the commands they accept and additional capabilities they give the operator for expansion of the system.

27

9.4.2

Mentor II Communications

The Mentor II DC drive uses a unique set of communication commands that permit many of the settings and parameters of the drive to be modied whilst the drive is in operation. For the purposes of the simulation the only parameters that are accessed is the torque reference, used to vary the torque at the generator through the DC motor, and the speed of the shaft, used for calculation of the tip speed ratio described in ??. Communication with the drive however, requires a series of parameter modications to disable the operation of the front panel of the drive, as well as a unique communication checksum requirement for each command. This checksum, referred to in the drive literature as the BCC, is required at the end of every command, and is calculated in the following fashion: 1. A progressive binary XOR is performed on all characters of the message after the start-of-text command parameter. 2. The nal XOR is the BCC if it exceeds 31, otherwise 32 is added. An example BCC calculation, extracted from the Mentor II User Manual, is shown below for clarity:

Figure 20: Example BCC calculation, Courtesy Control Techniques Messages transmitted without the checksum will be rejected by the drive, which will respond with a negative acknowledgment (NAK). The structure of messages sent to the drive, as alluded to in the BCC calculation, are comprised of a series of ASCII literal and control characters. The general structure of these messages, from the Mentor II User Guide, are as follows: Sending data reset address start-of-text menu + parameter 1 to 5 data characters end BCC 28

Requesting data reset address parameter end For data requests, the drive responds in the following form: start parameter 5 data characters end BCC The MATLAB function used by the simulation strips all but the data characters from the response automatically, however no error checking using the BCC is performed.

Figure 21: Mentor II DC drive front panel Using this method, drive parameters that a writable may be modied, however as the drive has been modied to accommodate local control via a front 29

panel 21, the parameters of the drive that are manipulated via serial communication will be overwritten by the input of these controls. As such, these controls must be deactivated by modifying the destination of these inputs to drive invalid parameters. This will then allow the simulation to freely modify values such as the torque reference without being overwritten. The parameters that are modied for this purpose are as follows: Set general purpose input 4 (GP4) destination, the analog torque reference control, to 0 (drive ground): reset 0011 (drive address 01, sent as 0011 for security) 0714 (menu 07, parameter 14) 0 end BCC Set external input 10 (F10), the speed-torque selector switch, to 0 (drive ground): reset 0011 0820 0 end BCC At this point, a reset of the drive is required to save the changes. This is then followed by writing the following parameters to the drive, show without control code framing: 0011 0408 0 : set the torque reference to 0 0011 0412 1 : set drive to torque control mode (in conjunction with 0413) 0011 0413 0 : set drive to torque control mode (in conjunction with 0412) The simulation is now able to communicate with the drive, which consists of the following parameters of interest: 0408 This parameter, the DC motor torque demand, is driven by the output of the simulation, to reect the aerodynamic torque of the blades on the generator. This value is written to by the PI controller detailed in 9.5.3. 0303 Requesting this parameter returns the shaft speed of the DC motor, in RPM. This parameter is used in the calculation of TSR after conversion to radian per second. Connection to the drive for the communication described above requires a non standard wiring of the serial cable. The cable used for the system was hand soldered for this purpose and uses the following connections:

30

Figure 22: Mentor II serial cable connections. Control Techniques.

9.4.3

Tektronix TPS 2024

The Tektronix TPS 2024 is a four channel digital oscilloscopes used as one of the feedback oscilloscopes whose purpose is outlined in ??. Communication with this device occurs over a standard null modem cable, used to connect two DTE devices together as dened in the RS-232 standard. This is the only device used in the hardware platform that communicates over a standard cable.

Figure 23: Tektronix TPS 2024 4 channel digital storage oscilloscope Commands used to communicate to the oscilloscope are outlined in the device programmer manual, which allows all device functions to be used remotely. The functions of interest to the simulation are related to reading in the root mean square (RMS) value of a single channel, explained in detail under 9.5.3. Whilst the oscilloscope is equipped with another 3 channels, these are not used to read in any other measurements by the simulation. The reasoning behind this choice is a result of the update speed of the traditional measurements 31

taken by the oscilloscope and displayed on its screen. These values are updated slowly, and measured infrequently, a characteristic that makes their use unsuitable for use in the simulation. There is included another, superior method of retrieving measurements from the oscilloscope in the form of immediate measurements. These measurements have no local equivalent, and are only available as a remote option. Values read by a remote system using this facility are taken by the oscilloscope as requested. It was experimentally observed that using the standard measurement facility, updates of the requested values occurred at a rate sucient to cause instability in the controller To use the immediate measurement facility, the following commands must rst be issued to the drive before reading is attempted. MEASU:IMM:SOU CH1 MEASU:IMM:TYP CRMS The commands need not be issued in this order, which simply place the immediate measurement source to channel 1 (CH1) and set the measurement value to be the cyclic RMS (CRMS). Once the oscilloscope has been congure for immediate measurements, the following command may be issued to retrieve the current RMS value: MEASU:IMM:VAL Issuing this command in too rapid a succession will cause the oscilloscope to become unresponsive to local user input, however it will still respond with immediate measurement values. However, if the rate of requests increases above this threshold, the oscilloscope will respond with an error. It should be noted that upon error, the Tektronix oscilloscope will respond with a value of 9.9E37, a condition which is caught by the simulation logic and substituted for zero. As an aside to the role both the Tektronix and GW Instek oscilloscopes play in the simulation, the operator is free to use the remaining channels of bot test instruments to take further readings, without aecting the serial data transfers. This allows the operator to perform a variety of other measurements, including use of the MATH functions of both instruments to monitor voltages and currents of additional equipment. 9.4.4 GW Instek GDX-820C

The nal system peripheral that communicates via serial to the simulation PC is the GW Instek GDS-820C oscilloscope, a 2 channel digital storage oscilloscope that is used to circumvent the issue of measurement readings from the Tektronix oscilloscope. As only a single source may be selected for these immediate measurements, a second oscilloscope is used to acquire readings of the second value of interest 9.5.3.

32

Figure 24: GDS-820C 2 channel digital storage oscilloscope

Unlike the Tektronix oscilloscope, there is only a single method of requesting values from the GW Instek; via a command referred to in the products programmer manual as MEASURE. This command, similar to the immediate measurements of the Tektronic oscilloscope, may only be active on a single channel for a single measurement at any one time. The commands used to place the oscilloscope in this mode are as follows: :MEAS:SOUR 1 This places the oscilloscope measurement mode on channel 1 (CH1). The oscilloscope may now be interrogated by issuing the following command: :MEAS:VRMS? The oscilloscope responds with the RMS value of CH1. The serial cable for the GW Instek oscilloscope, as per the instruments user manual, is wired as follows:

33

Figure 25: GDS-820C serial cable connections. Courtesy GW Instek. Both GW Instek and Tektronix oscilloscopes respond to requests of measurement values with an ASCII string in scientic notation, and is automatically converted to a number in the simulation. If verbose mode on either oscilloscope has been activated, an error will occur as there is no input sanitisation in the serial read functions for these devices has been implemented.

9.5

Compensation

In order to fully replicate the behavior of a real wind turbine, it is desirable for the emulation system to be as realistic as can be achieved. This section discusses some important considerations such as friction and running torque of a shaft, and how these things contribute to the performance of the system. It presents each of these issues and also discusses how to compensate for them.

9.5.1

Static Friction Compensation

James Derricott

In order for the shaft of the DC motor to begin rotating, the drive must rst overcome a friction which is holding it in equilibrium. This force, termed the stiction, will hold the shaft motionless until enough torque is applied to the shaft for rotation to begin. Once the shaft has started to rotate less torque will be required to keep it turning then the original starting torque that was necessary to overcome the static friction. The static friction is found and given a value by determining exactly how much torque is required to just begin the shaft rotating. Once this is determined it is possible to compensate for this eect by initially writing this extra amount to the drive, on top of the normal required amount given the set conditions, and hence this extra amount of torque will then overcome the friction and the shaft will then see the required torque and the friction will be eectively canceled out. It should be noted that shaft friction, be it static or running (to be discussed later), will be changed depending on the loading conditions of the shaft, so in practice for compensation to work eectively in this fashion, the friction torque

34

of the whole system must be determined, and not just the DC motor. In the emulation system the above idea was implemented as the use of a static friction compensation factor at zero drive speeds, until rotation is detected, for wind speeds above cut-in. It was initially decided to use an additional amount of torque in the case of a zero RPM when there was any input to the simulation (that is, wind), however this proved unsatisfactory as a non-zero RPM would be generated, disabling the additional torque amount added and cause the drive to stall. This was because there was a torque required to be added to the drive at all times in order to keep it rotating at the desired reference. This is the running torque, which is discussed int he next section. A brute force approach to friction is to assume that in order for the drive to properly overcome the stiction torque much more than the estimated value needs to be written, so for a short time a larger torque is written to the drive, enabling it to achieve some momentum and the shaft to avoid stalling and reverting back to the zero speed condition.

9.5.2

Running Torque Compensation

James Derricott & Bryan Hanson

Running torque is akin to stiction torque, but in a more general sense. Running torque is a friction torque that resists the applied torque while the motor is running. Running torque exists all all speeds but is not a constant value over the whole speed range, ranging from between 1 Nm at low speeds to almost 3 Nm as higher running speeds. In order to compensate for running torque it is necessary to write the running torque in addition to the current torque demanded. The simplest way to do this is to assume a constant value of running torque over the entire speed range. As the running torque is dramatically dierent over a wide speed range this is not a good approximation. A more eective use of the same strategy is to break the operation speeds into a number of ranges. Over these ranges it is assumed that the running torque is constant, and a lookup table can be used so that depending on the speed range the ad This table used a speed input and would output the additional amount of torque needed by the drive to simply rotate. Experimentally deriving this torque curve proved dicult, and was not repeatable. This is due to the large number of inuences the running torque was aected by. One of the main inuences was the duration of time the drive had been operational, as this seemed to warm up the bearings and as a result changed the running torque, meaning that extended periods of operation were seen to cause a decrease in the amount of additional torque required to keep the drive rotating. At this point it was decided to pursue an active compensation scheme utilising feedback that was capable of adapting to the varying running torque.

35

9.5.3

Active Compensation
Bryan Hanson

Active compensation is a method of combating the various loss mechanisms of the prime mover by using closed loop control on the feed forward torque demand. As the simulation calculates the generated blade torque, simply writing this demand to the DC drive will result in poor simulation accuracy. This is because the losses will reduce this torque to a lower value at the input shaft of the generator, which in turn, aects the rotational speed of the shaft, and results in the simulation stabilizing at a dierent point on the CQ - curve. The only way of ensuring that the generator receives the correct torque is to oset the losses with additional torque, ensuring that the desired torque at the generator is that which is desired. As nding the correct losses in any situation proved problematic, as detailed above, a unique approach was devised; by using the generator model previously derived for steady state testing, the mechanical torque on the generator could be calculated. Once the torque at the generator can be found, it becomes a matter of varying the torque demand to the DC drive above that calculated by the simulation until they are equal. This additional torque written to the drive is the torque loss of the system, and need not be calculated, only oset. The generator model, introduced previously in section 6, requires the RMS current, line-to-line RMS voltage and shaft speed of the generator to calculate torque; values which would need to be taken at regular intervals with a reasonably high accuracy. As the Mentor II drive includes a speed mode, the shaft speed of the generator could be found by interrogating the current speed of the DC motor, taken from an installed tachometer. As communication with the drive had already been established at this time; it became the obvious choice for providing the generator shaft speed. An investigation into acquiring the remaining measurements was performed, and it was found that existing equipment, a current and dierential voltage probe, could be used to extract the time varying signals required for further processing. The conversion of these AC signals to an RMS value was initially proposed to occur inside the simulation, by connecting the outputs of the two probes into the Mentor II drive for reading by the simulation PC.

Figure 26: Mentor II remote inputs 36

As shown above, the Mentor II drive front panel inputs for torque and speed have connectors to attach remote references, which feed analog inputs to a drive terminal block. Whilst both probes could have their attenuation adjusted to fall within the -10 to +10 voltage range of the analog input; the issue of reading the in the time varying AC into the simulation to extract the RMS value became problematic. The analog to digital conversion of the AC waveform, coupled with the latency of the serial communication link and simulation update frequency resulted in a waveform read by the PC that was not recognizable as AC. As such, the accurate extraction of the RMS value of both current and voltage of the generator output not found to be possible using this method. After a brief consideration of using RMS to DC converter chips to perform the AC to RMS calculation before the signals reach the drive, an inspection of available oscilloscopes found that RS-232 interfaces were present on a number of units. As these instruments were capable of calculating the RMS of a signal with high precision, and could communicate directly with the simulation PC over the same communications standard, it was decided to use this method to acquire the RMS measurements required by the generator model.

Figure 27: Feedback oscilloscopes Whilst the use of 2 oscilloscopes is claried in further detail in the serial communication section, 9.4, ultimately the function of these instruments is to communicate the RMS current and line-to-line voltage of the generator to the simulation PC. Here, the values are used to calculate the torque at the generator as per the model introduced previously in section 6, providing the feedback signal for a controller.

37

Initially, it was sought to use the Mentor II drive as the controller to accomplish this task; as the drive maintains robust internal control loops and would reduce the computational requirements of the PC for each simulation step. An investigation into this prospect found that whilst there was a current feedback parameter that could in theory be used to control the current demand to the motor, it was a read only value derived from internal current transformers. This was due to the role this measurement played in initiating drive and motor protection procedures, well as providing the drive operator with an indication of armature current. Once this limitation was discovered, control from within the simulation was investigated; using control blocks included in MATLABs library. Subsequent experimentation with a variety of controllers led to the choice of a discrete PI to perform the control action as it exhibited a fair balance between speed and stability. Tuning the controller for optimal performance was done manually, in an iterative fashion beginning with the proportional gain term, Kp . This value was increased incrementally in steps of 0.1 from 0 until the system became unstable; exhibiting oscillatory behavior. The largest stable Kp was then chosen as the proportional gain term of the controller, where the integral gain Ki is then incremented in a similar fashion to reduce the steady state error to zero. In addition to tuning the PI controller, experimentation with changing the rate of controller execution in the simulation was found to have an improvement on rise time without an increase in Kp ; however this line of modication was not pursued far due to time constraints. Due to the soft execution nature of the simulation, changing the computational requirements of the simulation steps by either adding or removing calculations will require a re tune of the PI controller. This requirement would most likely be relaxed if a suitable hard real-time execution target were used, options of which are detailed in section 9.3.3. Due to the nature of the compensation, the blade torque calculated by the system will always result in a lower value at the generator if written directly to the DC drive. This characteristic allowed a modication to the control loop to always write the calculated torque to the DC drive, in addition to the control action provided by the PI:

Figure 28: Modied control loop 38

This resulted in a substantial increase in transient performance, detailed further in 10.

9.6

Inertia
James Derricott

Inertia is a bodys resistance to changes in its motion, so for example a large heavy object would have a high inertia, or alternatively an object with its mass spread out in a large radius may also have a large inertia. In the wind turbine, there is inertia associated with the generator and shaft, but this is overshadowed by the inertia of the rotor and bade assembly, which has mass distributed along the blade radius which increases its inertia. In the emulation hardware, a large 30kW DC motor is being used, and due to its size has a large inertia which resists its ability to change speeds very quickly. This is oset by the large current (and therefore torque) that the drive can use to accelerate, with torque being related to acceleration via the formula; T = I Where T Torque, Angular acceleration and I Inertia of the system. In reality the inertia of the rotor and blades is higher than that of the motor, so in order for the emulation system to become more realistic it is necessary to limit the rate of change of acceleration of the DC motor to match that that the real turbine would achieve in practice. (15)

In order to calculate the inertia the DC motor was run to 1000rpm and then turned o and allowed to run down to zero speed, while the time to do so was recorded. This was also done with the generator which was then disconnected and timed. The inertia for the whole DC motor and generator system was found to be 0.864N ms2 /rad, while the inertia of the whole wind turbine was found to be 1.81N m2 /rad. This is not a surprising result due to much of the wind turbines mass being spread out at a further distance from the rotor axis due to the blades. If used in the emulation system the inertia will provide a way of determining the acceleration of the system, which can be matched to the real turbine to make the emulation respond more accurately. In eect the term will slow the emulation system down, as the extra inertia required to match reality will slow the acceleration down and it will be necessary to write the torque required as a ramping value of torque, with the ramp slope limited by the reduced acceleration of the system. 39

In Simulink this would be implemented as a torque ramping function block which would take as inputs the torque being written to the DC drive, and also the drive speed and simulation time step (note that the emulation system would have to be run in real-time using the real time target for windows). The ramp would have a gradient limited by the calculated acceleration term, with the starting value being dened simply by the current value of torque (before any system change, i.e pre- speed change), and would ramp up as dened by the acceleration (use the derivative block in simulink to take the derivative of the speed) until it reached the maximum limit as set by the new calculated value of torque. The simple delay and rate limiting blocks provided by Simulink will not be sucient here as the ramp rate (acceleration) will need to change dynamically based on the change in speed. The controller will need to be retuned for this as its performance is aected by the simulation speed.

9.7

Summary

In emulating the wind turbine it was necessary to use a number of dierent elements to achieve this aim. Starting from the 300W generator from the wind turbine, a 30kW DC motor was used as the prime mover to replicate the speed and torque behaviour expected of the shaft and blades in a real wind turbine. A DC drive was used to control the torque of the DC motor, and this in turn was controlled by a PC running Matlab/Simulink. Feedback of voltage and current was provided from communication with digital oscilloscopes which enabled accurate torque tracking. The software model that calculates the behavior of the DC motor has been programmed in MATLAB Simulink, executing in soft real time on a consumer PC running Windows XP. This system allows a great deal of exibility for the simulation operator as any system variables can be viewed in a variety of ways; and facilitates direct control of the input wind as the system is operating. Communication between hardware peripherals to the PC occurs over RS-232 and involves the use of 3 serial connections; the DC drive and 2 oscilloscopes. Active compensation using a PI controller uses measurements transmitted back to the simulation from these peripherals for closed loop control of the feed forward torque demand. The tuning of this controller was performed manually and exhibits acceptable transient response for the purpose of testing the steady state characteristics of power interface converters attached to the generator. Inertia aects the ability of the system to rapidly change from one torque to another, in eect limiting the rate at which it can do so. The inertia of the whole wind turbine was found to be much higher than that of the DC drive and generator system, due to much of the mass being spread out along the blades rather than concentrated near the shaft as then DC motor is. This inertia eect was never implemented in practise but it can be done by limiting the rate of change and by ensuring the system runs in real time. The cause of this would be to slow down the DC motors response to changed in required torque (input as wind speed changes) to match the response that the real wind turbine would have. 40

41

10
by Bryan

System performance

10.1

Outline

This section will investigate the performance of the emulation system to accuratly replicate the behaviour of the simulated wind turbine. Performance results will be analysed and any issues that arose during testing procedures will be noted. Following this, the dynamic performance of the system will be presented, including (what was messed up, the controller, no inertia)

10.2

Steady State performance

Evaluation of the steady state performance of the emulation system was performed by recreating the wind speed and loading conditions of the wind turbine performance data collected from wind tunnel tests detailed in ??. Only performance data at a single wind speed, 9 m , was collected for these tests; the full s results of which may be found in appendices ?? and ??. The test procedure followed that of the steady state testing, 2 resistive load banks in delta supplied a variable load to the generator; with measurements taken at steady state of the RMS current and line-to-line voltage. Additionally, measurements of various simulation quantities were recorded to show both the accuracy simulation calculations and illustrate the eect of active compensation. The terminology used in these results can be summarised as follows. Quantities under the Simulation legend are those which were measured from results obtained on the emulation test rig, which is designed to replicate the results of the Experimental results collated from testing performed with the real turbine in the wind tunnel. Shown below are the results of these tests,

42

Figure 29: Power vs. Loading condition The above gure shows the power generated by the simulation system test bench compared with that obtained from the steady state wind tunnel experiments. The simulation performs within an acceptable range of those values measured in the wind tunnel experiments, accurate enough to perform steady state testing of power electronic interface converters outlined in the introduction. It should be noted that magnitude loading denotes increasing load imposed on the turbine by way of the load banks, being the number of switches toggled. The following gure shows the voltage measurements taken for both the simulation and wind tunnel experiments; note the Y axis scale begins at 20V, the error is not as large as it appears:

43

Figure 30: Voltage vs. Generator power However, it can be observed that the voltage readings taken from the simulation are consistently lower than those from the wind tunnel tests. The magnitude of this dierence is not large enough to negatively impact performance testing of power converters attached to the generator and is therefore within acceptable limits.

44

Figure 31: Current vs. Generator power The current obtained from the simulation system follows the actual turbine quite closely; yet exhibits similar behavior to that of the voltage. As such, although there is room for improvement the margin is quite small.

45

Figure 32: Electrical frequency vs. Generator power Electrical frequency measurements taken from the simulation system can be seen to converge at higher power levels, although the largest error that occurs is at the no load condition and is only 0.5Hz or within 98% of the experimental value from the wind tunnel tests.

46

Figure 33: Tip speed ratio vs. Generator power TSR values obtained from the simulation rig appear to converge with the experimental values obtained from the real turbine, however, similar to the frequency the largest error is within acceptable limits for the intended usage scenarios.

47

Figure 34: RPM vs Generator power The RPM measurements read from the drive can be seen to introduce an error into the simulation; and appears to be less accurate than using the electrical frequency to derive the speed of the generator. Substituting the speed input to the system for an oscilloscope reading was not performed, reasoning behind this decision may be found in Section 9.4.

48

Figure 35: Torque vs. Generator power As can be observed, the magnitude of additional torque required to compensate for losses in the system Compensation, varies with the operating condition of the drive. In addition to this, the simulation blade torque is calculated to be higher than the experimental blade torque over all operating conditions. This in contrast to the calculated torque at the generator by the simulation, which although it lies on the same line; is at dierent points.

10.3

Dynamic performance

The dynamic performance of the system was not extensively tested, only the transient response of the system to a series of rapid load and wind changes was performed. These tests were made as part of the controller testing outlined in Section 9.5.3, and represent the controller behaviour of the nal

49

Figure 36: Step response to a load increase It can be observed that the system overshoots the reference torque and oscillates slightly before obtaining a steady state error of zero. Note the large amount of aliasing present in the system due to a combination of soft real time execution and latency resulting from serial communication. Below, the result of a load decrease of the same magnitude is shown:

Figure 37: Step response to a load decrease Observe that the transient response appears to have improved in comparison to the load increase situation, however a steady state error exists for considerably longer. Further dynamic performance testing was deemed inappropriate given the incompleteness of the system with respect to replicating the dynamic performance of the turbine. This includes the lack of inertia modelling and the suboptimal control detailed both above and in Section 9.5.3. It should be noted however that at the time of writing, site data from a remote turbine installation was being prepared and collated for testing perfor50

mance of the simulation system.

10.4

Summary

This section has presented both the steady state and dynamic performance of the turbine and demonstrated that the performance of the emulation system is sucient to

51

11

Further work

In many projects there are extensions and further work that can be done to further improve and polish the nal outcome. Although this project has achieved all the original aims and goals there is still further improvements and renements that can be done to give a more accurate and more realistic result. Some of these ad For completeness sake more investigation needs to be made of why the CpTSR curve predicted by the data measured using the aerofoil in the small wind tunnel does not break and decrease past a TSR of 6. Up until 6 it appears close enough to allow a comparison between the Cp-TSR curves from the aerofoil and the turbine itself, but after a TSR of 6 the curve from the aerofoil keeps rising and does not decrease at all. There are no currently explanations for why that is the case. In order to improve the emulation performance and make it more realistic there are two main suggestions. To allow the system to emulated dynamic behaviour of a wind turbine (i.e transient bahaviour as the turbine changes form one steady state wind condition to another), it is necessary to make the PI controller response a lot faster than it currently is. Currently the controller takes a very long time to achieve steady state performance with zero error, and to become dynamic it would need to be in the order of ten times faster. It is likely that the delay in controller behaviours is closely tied with the speed at which the feedback system operates. The feedback must interrogate the oscilloscopes for voltage and current information and then use the generator model to determine the torque before the controller can operate on the error signal. There may be other factors causing or contributing to the delay, and all possible cause would need to be investigated. The second recommendation to improve performance is to change the rate of acceleration of the emulation system to match the real turbine. This is achieved using the inertia of the wind turbine to limit the accelerating torque to achieve the same rate of change of torque in the emulation system as in the real turbine. In order for this to be realistic the emulation system will have to be used in real time which in Simulink uses hardware interrupts to ensure real time operation.

52

12

Conclusion

The aim of creating an emulation system was to facilitate testing of power electronic devices for maximising the power output of a generator, in a controlled environment. A low power wind turbine emulation system was constructed using a DC motor as the prime mover, which was by a DC drive and a PC running Matlab/Simulink. This parallel simulation read in speed signals and used them to calculate the Tip Speed Ratio and in turn the Torque Coecient (CQ ) which was used to calculate the required output torque for a given wind speed. This torque command was then sent to the drive and the DC motor. Due to friction losses in the shaft it was necessary to write more torque then the calculated value, and this was calculated as the error between the required torque and the actual torque at the generator, given by feeding back the voltages and currents into a model of the generator. This error was then controlled by a PI controller which forced the steady state error to zero. The speed of the controller was not enough to make the system capable of being able to accurately respond to dynamic changes as wold happen under real wind conditions, but under steady state conditions (where the system is not constantly changing) the emulation performance matched that of the real wind turbine very closely, enough to say that the emulation system can successfully replicate the behaviour of a low power wind turbine under steady state conditions.

53

References
[1] Small urban wind turbine. http://commons.wikimedia.org/wiki/Image:Urbine221dc.jpg, October 2008. [2] J. C. M. Ovando, R.I.; Aguayo, Emulation of a low power wind turbine with a dc motor in matlab/simulink, in Power Electronics Specialists Conference, pp. 859864, 2007. [3] J. M. J.F. Manwell and A. Rogers, Wind Energy Explained; Theory, Design and Application. John Wiley & Sons, Sep 2002. [4] S. Mathew, Wind Energy, resources, resource analysis and economics. Springer, Feb. [5] D. Parker, Computer based real-time simulator for renewable energy converters, in Electronic Design, Test and Applications, pp. 280284, 2002. [6] M. Sacher, Characterisation of a low power wind turbine generator, 2008/2009.

54

13

Appendices

55

13.1

Appendix A: Startup and Initialisation Procedures

James Derricott

Setup, Startup and Running Procedures:

By James Derricott

In addition to this document there is a startup video that may help to visualise the startup procedure. It is to be used in conjunction with this document.

The computer to be used for the Wind Turbine Test Set is located next the motor-drive system.

Log on as user dghug with the password mosfet, or alternatively use another account to log on, and then access dghugs documents via My Computer. It is better to access via the logon.

Once you have logged in, start Matlab 2007a from the desktop icon. Ensure that you use 2007a and not 2007b.

Once you have started Matlab, change the current directory to dghugs documents and then Matlab and nally to the Cq-turbine folder.

Set up the physical connections on the system.

Make sure rst that you have all equipment needed: Lab PC MentorII DC drive and 30kW motor 300W generator Voltage probe connected line-to-line across the 3 phase output of the wind turbine generator. Connect to channel one of the GWInstek oscilloscope. Set this to 50x voltage and adjust the GWInstek oscilloscope to 1x voltage. This sounds unusual but the GWInstek oscilloscope does not have a setting for 50x, this is instead adjusted inside the simulation. Black clamp current probe connected to the output of one of the phases of the generator. This should be set to 10mV/A. Connect this to channel one of the Tektronix TPS oscilloscope and adjust the oscilloscope to match the current probe. 56

Connect serial cable to drive and oscilloscopes (it is important that the correct cable connects to the correct destination).

Serial cable with one stripe of yellow tape goes from COM1 on PC to the serial port on inner right of drive.

Serial cable with two yellow tapes stripes from COM3 to the back of a GW Instek GDS-820C (available from the undergraduate labs in building 35).

Connect the third Null-Modem cable with three yellow stripes of tape from COM4 to the back of a Tektronix TPS 2024 oscilloscope (there are only two of these available).

Now the drive itself can be turned on. To do this rotate the large handle near the bottom left to the ON position. This applies power to the drive. Now push the rst red switch to ON. DO NOT enable the drive at this time.

Now we can initiate the drive startup procedure before running the simulation. In the matlab Cq turbine folder that the current directory is set at, you will see a le called torque mode.m. Open this le. Run the rst 2 lines of code. You can do this by copying them into the matlab command prompt or by right clicking and selecting evaluate current cell.

% GP 4 Destination (disable front panel torque control) cli serial write('0011','0714','0') % F 10 (external input) Destination (disable speedtorque selector) cli serial write('0011','0820','0')

Now you must RESET the drive for these changes to take eect. Press the RESET switch on the right hand side of the drive operator interface.

Now run the next set of code:

% Torque Reference (set from 95% to 0%) cli serial write('0011','0408','0') % % % | 4.12 | 4.13 | % %| 0 | 0 | Speed Control % %| 1 | 0 | Torque Control % %| 1 | 0 | Torque Control + Stepped Override% % %

57

% Set cli serial write('0011','0412','1') cli serial write('0011','0413','0')

Check parameter 04.08 to make sure this has been set to zero. This parameter is the torque reference. Initially we dont want the drive to write any torque so we check this parameter to ensure that we have not made a mistake.

Now we can open the simulation. Type startup sim into the Matlab command line prompt.

Running this le initialized all parameters used in the simulation, such as wind data, torque coecients, tip speed ratio data etc. It also opens the serial port for communication with the drive and also the oscilloscopes and opens the simulation. Note that when shutting down the simulation you must also run shutdown sim to ensure that the serial ports are closed else you will get an error the next time you try to open it.

To begin the simulation you must press the ENABLE switch on the drive, and then press the start simulation button in the Simulink simulation.

(This step is not implemented in the current conguration): If you happen to be using the real time target for windows, you will rst need to Build the model, then Connect to target, then start real time simulation (mode must be set to external and the simulation step size must be a xed step).

Once you have done this the user can change the input wind speed by varying a slider GUI that should have open when the simulation did.

You can watch instantaneous position on the Cq-TSR curve via the gure provided. You can also see various other parameters user the scope manager, but this is set up by the user.

When nished you should rst switch the enable switch to DISABLE the drive before then stopping the simulation.

Do not forget to run shutdown sim.m rather than simply exiting the simulation.

58

Common problems, solutions & FAQ: Check that you followed the startup procedures above correctly and not missed any steps. If the issue still persist some solution to common problems are listed below. For further help call Bryan Hanson. He wont mind at all.

Have you tried turning it o an on again? This sounds like a joke but this often solves the problem. Depending what the problem is you may have to turn the drive o (remember to use the Torque mode commands to re-initialise it), you may turn the oscilloscopes o if they are causing trouble, and also you can restart Matlab. If you are restarting matlab remember to once again run startup sim, because once matlab has shutdown it automatically closes all serial objects.

I get an error when I try to run startup sim:

??? Error using ==> serial.fopen at 71 Port: COM1 is not available. Available ports: COM2, COM3, COM4. Use INSTRFIND to determine if other instrument objects are connected to the requested device. Error in ==> startup sim at 24 fopen(s obj)

This error is because when running startup sim you are enabling the serial port for communication with the drive. This error is because you are trying to enable something that is already enabled, i.e. the serial port is already open. The most likely cause of this error is incorrect shutdown the last time the simulation was run. Running shutdown sim should solve this problem.

Alternatively you can open the le shutdown sim in the m-le editor. This le is located in the main project directory which should be set as your current Matlab path.

At the end of this le there is a few lines of code as below:

%// Close Serial Object obj = instrfind; fclose(obj); delete(obj); clear obj;

Either copy this code into the Matlab command or execute this cell. This code will close the serial port. Following that you may again initiate startup sim. Running shutdown sim should run this code automatically, so this should x the problem as well.

59

Turning Matlab o and on again works as well. An error will result when running startup sim if the oscilloscopes are not on and connected to the PC, because Matlab will attempt to open serial ports that are not connected. So make sure all devices are plugged in and turned on before running startup sim.

60

13.2

Appendix B: Aerofoil Testing Code

James Derricott

% % Aerofoil Testing % James Derricott % September 2008 % % Undergraduate Thesis, Wind Turbine Test Set % Monash University % %% close all clear all %% Vw = 13.4; % Wind velocity (m/s) endplates = 1; % endplates = ON/OFF add/remove the end effects for RPM = 300:100:1000 % RPM = shaft speed (rpm)

% Outputs: % % Cp = power coefficient % Cq = torque coefficient % tsr = tip speed ratio % % %% Relative speeds and relative angles of blade elements: % % % % % % % TERMS: Vw = Wind velocity Vr = tangential element velocity at some point in time Ve = effective velocity wt = total angular velocity of the blade wr = angular velocity of the blade element == wt ar = effective angle of the blade element % Closes all figures that were previously open % Clears all data/variables from the workspace % Number of blades on wind turbine

% close all; % clear all; num blades = 3; %% R = 1.067; rho = 1.21;

% Total blade length (m) % Density of air % Radial speed of the shaft % Size of each blade element (m) % dr is the blade elements (m) % Instantaneous tangential velocity % of the blade element % Effective velocity at each blade % element along the blade

wt = (2*pi/60)*RPM; element size = 0.01; elements = (0:element size:R); Vr = wt.*elements; Ve = sqrt((Vw2)+(Vr.2));

ar = (atan(Vw./Vr))*(360/(2*pi)); % ar is the blade element angle

% for each blade element in d

61

% This angle is the difference between the Effective velocity % and the Wind velocity %% Load Lift and angle if endplates == 0 load Lift NOendplates; lift = Lift NOendplates; load angle NOendplates; angle = Angle NOendplates; else load Lift WITHendplates; lift = Lift WITHendplates; load angle WITHendplates; angle = Angle WITHendplates; end %% Load Drag and angle if endplates == 0 load Drag NOendplates; drag = Drag NOendplates; else load Drag WITHendplates; drag = Drag WITHendplates; end %% Lift for each element: % Need to restrict blade element angles to 45deg, % and also use only the ve angles for lift % (for usage make the angles +ve numbers for the comparison) ar = ar'; % Remove all elements that are <45degrees while (ar(1)45) %&&numel(ar)|=0 ar(1)=[]; end % Remove all positive angles from the lift angles, % leaving only negative angles while (angle(1)0) angle(1)=[]; end % Restrict Lift to these same values: while (length(lift)>length(angle)) lift(1) = []; end % Inverse the angle value so that they can be % compared to the blade element angles: ar = ar; %% % Using jdlookup to find the approximate lift % values for blade element angles % [match] = jdlookup(find, refX, refY) Lr = jdlookup(ar,angle,lift)/(element size1); ar = ar; % change back to the correct sign

%% Need to find torque from the lift

62

% Blade elemetns corresponding to lift El start = length(elements)length(Lr); %length(Lrt); Lelements = elements(El start+1:length(elements))'; % Torque for each blade element Tr = Lr.*Lelements; %Lrt.*Lelements; %% Total Lift contributing to torque % To find total Lift in the tangential direction % of the wind turbine, sum the elements of the toque % and multiply by number of blades. Ttot = num blades*sum(Tr); %% Power % Power = torque*angular speed P = Ttot*wt; % Power the turbine is producing %% TSR Tip Speed Ratio % TSR = Speed of blade tip/speed of wind Vtip = wt*R; tsr = Vtip/Vw; %% Cp Power cooeficiant % Cp = blade power / [ 1/2 * rho * pi * R2 * Vw3 ] Cp denom = (0.5*rho*pi*(R2)*(Vw3)); Cp = P/Cp denom; %% Cq torque cooefficient % Cq = Cp/tsr Cq = Cp/tsr; %% fprintf('RPM \t Ttot \t\t P \t\t Cp denom \t Cp \n') fprintf('%.2i\t\t', RPM); fprintf('%.2f\t', Ltot); fprintf('%.2i\t', P); fprintf('%.2i\t', Cp denom); fprintf('%.2f\t', Cp); fprintf('\n\n'); %% plot(tsr,Cp, 'o'); xlabel('TSR'); ylabel('Cp'); hold on end

63

function match = jdlookup(find, refX, refY) % % This is my own approximating lookup table % this in noninterpolating, it simply find the closest matching value % and gives the output corresponding to that value. % % [match] = jdlookup(find, refX, refY) % % Inputs: % find values you are trying to determine Y values for % refX reference column X, the column you wish to compare "find" to % refY ref column Y the values you wish to output % % Output: % match matching values of Y % % % James Derricott 2008 % for n=1:1:length(find) % Compare find with each element value in refX % Take the difference from each element: d X = abs(refXfind(n)); % indX will give the closet match to the value "find" [min dX indX] = min(d X); % Matching refY value is found at the index indX match(n,:) = refY(indX); n = n+1; end end % End jdlookup function

64

13.3

Appendix C: DC drive serial communication code

In order to communicate with the DC drive you need to create a serial object.

%% Serial Port For the Mentor II DC drive global s obj; s obj = serial('COM1','BaudRate',9600); % COM1, COM2, COM3: Must be COM1 or cannot talk to drive. s obj.DataBits = 7; s obj.Parity = 'even'; s obj.StopBits = 1; s obj.Terminator = 3; s obj.Timeout = 10; fopen(s obj)

Once the serial communication has been enable the follwing code is used to write parameters to the drive;
function [A] = fun serial write(add,param,data) global s obj A = 1; %/// Truncate to a length of 5 if length(data)>5 data(6:length(data)) = []; end %/// BCC calculation loop % progressive XOR from param to ETX inclusive bin = double(dec2bin([param data hex2dec('03')],7))48; bcc = xor(bin (1,:),bin (2,:)); for i=3:size(bin ,1) bcc = xor(bin (i,:),bcc); end asc bcc = bin2dec(num2str(bcc)); if asc bcc < 32 asc bcc = asc bcc + 32; end BCC = char(asc bcc); %/// Serial Write fprintf(s obj,'\x04%s',add); fprintf(s obj,'\x02%s',param); fprintf(s obj,'%s',data); fprintf(s obj,'\x03%s',BCC);

In order to read back from the drive the following code is used;
function [reply response] = fun serial read(add,param) global s obj A = 1; %/// Serial Write fprintf(s obj,'\x04%s',add); fprintf(s obj,'%s\x05',param); reply = fscanf(s obj); reply data = reply(length(reply)5:length(reply)1); % Extract response reply resp = str2num(reply data); % Must change to small number if zero.

65

% Note str2double is fast, % but only operates on scalars reply response = reply resp; if reply response==0 reply response=0.1; end

On order to communicate with the drive in a standalone fahsion, you can use the following code tihout needing to open the serial port as the code will open and close it itself. The follwing is to write to the drive standalone;
function [] = cli serial write(add,param,data) %/// Serial Configuration s obj = serial('COM1','BaudRate',9600); % Create Serial Object s obj.DataBits = 7; s obj.Parity = 'even'; s obj.StopBits = 1; s obj.Terminator = 3; % ETX Terminator s obj.Timeout = .1; % 100ms Timeout %/// BCC calculation loop % progressive XOR from param to ETX inclusive bin = double(dec2bin([param data hex2dec('03')],7))48; bcc = xor(bin (1,:),bin (2,:)); for i=3:size(bin ,1) bcc = xor(bin (i,:),bcc); end asc bcc = bin2dec(num2str(bcc)); if asc bcc < 32 asc bcc = asc bcc + 32; end BCC = char(asc bcc); %/// Serial Write fopen(s obj); % Open Serial Object fprintf(s obj,'\x04%s',add); fprintf(s obj,'\x02%s',param); fprintf(s obj,'%s',data); fprintf(s obj,'\x03%s',BCC); %/// Serial Read % reply = fscanf(s obj); % reply data = reply(length(reply)5:length(reply)1); % Extract response % reply response = str2num(reply data); %/// Close fclose(s obj) delete(s obj)

The following is to read from the drive standalone;

function [reply response] = cli serial read(add,param) %/// Serial Configuration s obj = serial('COM1','BaudRate',9600); % Create Serial Object s obj.DataBits = 7;

66

s s s s

obj.Parity = 'even'; obj.StopBits = 1; obj.Terminator = 3; % ETX Terminator obj.Timeout = .1; % 100ms Timeout

%/// Serial Write fopen(s obj); % Open Serial Object fprintf(s obj,'\x04%s',add); fprintf(s obj,'%s\x05',param); %/// Serial Response reply = fscanf(s obj); reply data = reply(length(reply)5:length(reply)1); % Extract response reply response = str2num(reply data); %/// Close fclose(s obj) delete(s obj)

67

13.4

Appendix D: Oscilloscope Serial Communication Code

As with the DC drive, it is necessary to open serial ports to both the Tektronixs and the GWInstek digital oscilloscopes, which are done the follwing way respectively;
%% cs cs cs cs cs cs cs Serial port for the Tektronix TPS2024 Osciloscope obj = serial('COM4','BaudRate',9600); % Create Serial Object obj.DataBits = 8; obj.Parity = 'none'; obj.StopBits = 1; obj.Terminator = 'CR'; obj.FlowControl = 'hardware'; obj.Timeout = 2;

%/// Serial Configuration for GW instek GDS820C gws obj = serial('COM3','BaudRate',9600); % Create Serial Object gws obj.DataBits = 8; gws obj.Parity = 'none'; gws obj.StopBits = 1; gws obj.Terminator = 'LF'; gws obj.FlowControl = 'none'; gws obj.Timeout = 2;

This next segment of code is the function used for reading data from the Tektronix oscilloscope. Note that writing commands to either oscilloscope is not necessary as they are only being used to provide voltage and current readings.
function [reply] = fun serial read cro(cs obj,time,arg) if mod(time,50) = 0 reply = '1'; else fprintf(cs obj,arg); reply = fscanf(cs obj); end

The GWInstek works excatly the same, the only dierence is that it required a dierent function to the one above as they talk using dierent serial ports.

68

13.5

Appendix E: Torque mode.m

Torque mode.m is used when initialising the DC drive before it can be used and communicated with. The rst cell is run (cntrl-enter with that cell selected), then the drive is reset, then the second cell is run (cntrl-enter). The other code is for testing purposes and also for running in speed mode rather than torque mode.

%% % GP 4 Destination (disable front panel torque control) cli serial write('0011','0714','0') % F 10 (external input) Destination (disable speedtorque selector) cli serial write('0011','0820','0') %% % % % RESET HERE % % % %% % Torque Reference (set from 95% to 0%) cli serial write('0011','0408','0') % % % | 4.12 | 4.13 | % %| 0 | 0 | Speed Control % %| 1 | 0 | Torque Control % %| 1 | 0 | Torque Control + Sepped Override % % % % Set cli serial write('0011','0412','1') cli serial write('0011','0413','0') %% % 5% (50) == 100RPM % (50/100) == 1 RPM % scale by 6.31579 to change form Nm torque to % full rated torque % 5Nm with 6.31579 scaling == 4.72 % 15Nm with 6.31579 scaling == 16.5 to 17 %% torque = 2; % Nm cli serial write('0011','0408',num2str(round(6.31579*torque))); cli serial read('0011','0303') %% torque mode for changin torque wile ruuning simulation torque = 2; % Nm fun serial write('0011','0408',num2str(round(6.31579*torque))); fun serial read('0011','0303')

%% % Speed Mode % Change Speed Reference to 01.18 cli serial write('0011','0114','1') cli serial write('0011','0115','0') cli serial write('0011','0118','0') %% % % RESET HERE % %%

69

speed = 0; % RPM cli serial write('0011','0118',num2str(round(.5*speed))); %% % To read speed (in rpm) cli serial read('0011','0303')

70

13.6

Appendix F: Startup sim.m

Startup sim.m is to be run before atrting the simulation. It initialises all variables used in the simulation, and it also opens and initialises all necessary serial ports for sommunication with the DC drive and the oscilloscopes. It then opens the simulation itself.

%/// Turbine Simulation Startup Script %/// Clear the Workspace clear all %/// Simulation Parameters load Cq % Load Cq Lookup Table %load running % Load running torque + stiction ro air = 1.25; % 1.03% Density of Air cut in = 3.1; % 3.1; % Cut In Wind Speed cut out = 25; % Cut Out Wind Speed drop out = 1.95; % Drop out wind speed at which blades stop turning R = 1.067; % 1; % Blade Radius load WIND6 % Load wind data %% Serial Port For the Mentor II DC drive global s obj; s obj = serial('COM1','BaudRate',9600); % COM1, COM2, COM3: Must be COM1 or cannot talk to drive. s obj.DataBits = 7; s obj.Parity = 'even'; s obj.StopBits = 1; s obj.Terminator = 3; s obj.Timeout = 10; fopen(s obj) %% cs cs cs cs cs cs cs Serial port for the Tektronix TPS2024 Osciloscope obj = serial('COM4','BaudRate',9600); % Create Serial Object obj.DataBits = 8; obj.Parity = 'none'; obj.StopBits = 1; obj.Terminator = 'CR'; obj.FlowControl = 'hardware'; obj.Timeout = 2; % 100ms Timeout

%/// Serial Write fopen(cs obj); % Open Serial Object fprintf(cs obj, 'MEASU:IMM:SOU CH1'); fprintf(cs obj, 'MEASU:IMM:TYP CRMS');

% MAXI, CRMS

%% % startup GW instek GDS820C read %/// Serial Configuration gws obj = serial('COM3','BaudRate',9600); % Create Serial Object gws obj.DataBits = 8; gws obj.Parity = 'none'; gws obj.StopBits = 1; gws obj.Terminator = 'LF'; gws obj.FlowControl = 'none'; gws obj.Timeout = 2; % 100ms Timeout

71

%/// Serial Write fopen(gws obj); % Open Serial Object % set source fprintf(gws obj, ':MEASure:SOURce 1'); % fprintf(gws obj, ':MEASure:VRMS?'); %% %/// Open Simulation open system('turbine sim'); %% %/// Open GUI turbine gui.m %% % Create figure to plot Cq curve in real time figure('Name','CqTSR','NumberTitle','off') axis([0 8.5 0 .05]) % create axis title('CqTSR'); xlabel('TSR'); ylabel('Cq'); %colordef white % Normal colour scheme set(gcf, 'color', [0.7,0.7,0.7]); % Figure background colour set(gca, 'color', [0.8,0.8,0.8]); % Axes background colour hold on plot(linspace(0,8,8000), Cq, 'b');

72

13.7

Appendix G: shutdown sim.m

Shutdown sim.m is run when the user has nished using the emulation simulationn and wasnts to shut down. Running the script will close all serial objects and save and shutwon the simulation.

%% Close All open Serial Objects obj = instrfind; fclose(obj); delete(obj); clear obj; %% Turbine Simulation Shutdown Script % Clear the Workspace clear all close all % Close Model save system('turbine sim') close system('turbine sim')

73

13.8

Appendix H: Accompanying CD directory listing

02:32 PM <DIR> . 02:32 PM <DIR> .. 02:32 PM 63,419 turbine_sim.mdl 02:32 PM 4,080 turbine_gui.m 02:32 PM 1,568 turbine_gui.fig 02:32 PM 1,655 torque_mode.m 02:32 PM 2,132 startup_sim.m 02:32 PM 2,132 startup_sim.asv 02:32 PM 266 shutdown_sim.m 02:32 PM 629 fun_serial_write.m 02:32 PM 187 fun_serial_read_gwinst.m 02:32 PM 402 fun_serial_read_cro.m 02:32 PM 473 fun_serial_read.m 02:32 PM 362 curveplot.m 02:32 PM 994 cli_serial_write.m 02:32 PM 1,268 cli_serial_read_cro.m 02:32 PM 615 cli_serial_read.m 02:32 PM 565,017 WIND7.MAT 02:32 PM 432,797 WIND6.MAT 02:32 PM 851,093 WIND2.MAT 02:32 PM 57,766 Cq.mat 19 File(s) 1,986,855 bytes 2 Dir(s) 4,622,942,208 bytes free 09:39 PM <DIR> . 09:39 PM <DIR> .. 10:11 PM 223,197,184 Instructional video.MPG 09:53 PM 432,803,840 transient.MPG 10:32 PM 178,876,416 load demo.MPG 10:25 PM 96,854,016 wind demo.MPG 10:34 PM 1,599,197,184 performance testing.MPG 5 File(s) 2,530,928,640 bytes 2 Dir(s) 4,622,942,208 bytes free

<WTSim> 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008 10/10/2008

<WTMovie> 09/10/2008 09/10/2008 09/10/2008 09/10/2008 09/10/2008 09/10/2008 09/10/2008

74