emulation of a low power wind turbine

7/30/2019 Emulation of a Low Power Wind Turbine

1/81

Emulation of a Low Power Wind Turbine

using a DC Motor

James Derricott &

Bryan Hanson


2/81

1 Abstract

This thesis, Emulation of a Low Power Wind Turbine with a DC Motor, presentsan emulation system designed to recreate the behaviour of a 300W wind turbinewith zero steady state error.

The system uses a DC motor as the prime moved to replicated the behaviourof the wind turbine shaft and is controlled using a parallel simulation in Mat-lab/Simulink, This simulation takes speed as input from the DC drive, calculatesthe tip speed ratio and uses this to look up a value for the torque coefficientwhich 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 intoa characterised generator model and the torque present on the generator can be

directly calculated, which is compared with the required torque giving rise toan 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 afeed forward path, while the PI operating on the error signal forms the standardcontrol path.

Under steady state wind conditions the emulation system matches the em-ulated wind turbine with enough accuracy to achieve the original aim of theemulation system and is a good representation of a low power wind turbine.

ii


3/81

2 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 andhis help in testing the wind turbine.

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

Thank you to Martin from the electrical workshop for helping in the construc-

tion of the aerofoil test set.

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

Thank you Peter.

The authors James Derricott and Bryan Hanson can be contacted furtherat [email protected] and [email protected] respectively.

iii


4/81

3 Glossary of terms

Aerofoil Blade of the turbine which generated the lift force required to produce theturbine force, or torque, which turns the blades of the turbine.

Cp The Power Coefficient defines the energy the turbine has extracted fromthe wind, and it is denoted by Cp, and is defined as the ratio of the powerextracted from the air to the power available in the airThis power coefficient will vary based on something called the Tip SpeedRatio (see below).

TSR Tip Speed Ratio, () - Ratio of the speed of the rotor tip speed to thespeed of the incoming wind stream. The Cp curve will be a maximum for

some unique tip speed ratio

Cq Torque coefficient, found by dividing the Cp by the TSR

CT Thrust coefficient

TT Torque developed by the rotor

HAWT Horizontal Axis Wind Turbine

VAWT Vertical Axis Wind Turbine

E Kinetic Energy

Density of air 1.21 kg/m3 is used in the system

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)

iv


5/81

Contents

1 Abstract ii

2 Acknowledgments iii

3 Glossary of terms iv

4 Introduction 1

5 Wind Power 2

5.1 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.2 Wind energy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25.3 Wind energy conversion systems . . . . . . . . . . . . . . . . . . 25.4 WECS Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 45.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

6 Generator Modeling 6

7 Aerofoil characteristics 8

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87.2 Tip loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97.3 Cp curve comparison . . . . . . . . . . . . . . . . . . . . . . 127.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

8 Steady State Testing 16

8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168.2 Wind tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168.3 Cp curve derivation . . . . . . . . . . . . . . . . . . . . . . . . . 178.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

9 Emulation System 20

9.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209.2 Hardware Description . . . . . . . . . . . . . . . . . . . . . . . . 209.3 Emulation software . . . . . . . . . . . . . . . . . . . . . . . . . . 21

9.3.1 Modularity . . . . . . . . . . . . . . . . . . . . . . . . . . 229.3.2 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229.3.3 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . 249.3.4 Schematic . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

9.4 Serial communication . . . . . . . . . . . . . . . . . . . . . . . . . 26

9.4.1 RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279.4.2 Mentor II Communications . . . . . . . . . . . . . . . . . 289.4.3 Tektronix TPS 2024 . . . . . . . . . . . . . . . . . . . . . 319.4.4 GW Instek GDX-820C . . . . . . . . . . . . . . . . . . . . 32

9.5 Compensation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349.5.1 Static Friction Compensation . . . . . . . . . . . . . . . . 349.5.2 Running Torque Compensation . . . . . . . . . . . . . . . 359.5.3 Active Compensation . . . . . . . . . . . . . . . . . . . . 36

9.6 Inertia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

v


6/81

10 System performance 42

10.1 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4210.2 Steady State performance . . . . . . . . . . . . . . . . . . . . . . 4210.3 Dynamic performance . . . . . . . . . . . . . . . . . . . . . . . . 4910.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

11 Further work 52

12 Conclusion 53

13 Appendices 55

13.1 Appendix A: Startup and Initialisation Procedures . . . . . . . . 5613.2 Appendix B: Aerofoil Testing Code . . . . . . . . . . . . . . . . . 6113.3 Appendix C: DC drive serial communication code . . . . . . . . . 65

13.4 Appendix D: Oscilloscope Serial Communication Code . . . . . . 6813.5 Appendix E: Torque mode.m . . . . . . . . . . . . . . . . . . . . 6913.6 Appendix F: Startup sim.m . . . . . . . . . . . . . . . . . . . . . 7113.7 Appendix G: shutdown sim.m . . . . . . . . . . . . . . . . . . . . 7313.8 Appendix H: Accompanying CD directory listing . . . . . . . . . 74

List of Figures

1 A small HAWT. (1) . . . . . . . . . . . . . . . . . . . . . . . . . 42 Emulation system from (2) . . . . . . . . . . . . . . . . . . . . . 53 Generator equivalent circuit . . . . . . . . . . . . . . . . . . . . . 64 Star Equivalent Generator Model . . . . . . . . . . . . . . . . . . 7

5 Aerofoil Testing Rig . . . . . . . . . . . . . . . . . . . . . . . . . 97 Lift vs angle with endplates . . . . . . . . . . . . . . . . . . . . . 108 Drag vs angle with no endplates . . . . . . . . . . . . . . . . . . 109 Drag vs angle with endplates . . . . . . . . . . . . . . . . . . . . 1110 Cp-TSR curve WITH endplates . . . . . . . . . . . . . . . . . . . 1311 Cp-TSR curve WITHOUT endplates . . . . . . . . . . . . . . . . 1312 Cp-TSR curve comparison . . . . . . . . . . . . . . . . . . . . . . 1413 Turbine in Monash University wind tunnel . . . . . . . . . . . . . 1614 Experimental Cp-TSR Curve . . . . . . . . . . . . . . . . . . . . 1815 Emulation System Setup . . . . . . . . . . . . . . . . . . . . . . . 2016 Measurements & plotting capabilities . . . . . . . . . . . . . . . . 2317 Live CQ- curve plotting . . . . . . . . . . . . . . . . . . . . . . . 2418 Simulation model . . . . . . . . . . . . . . . . . . . . . . . . . . . 2519 Core turbine simulation . . . . . . . . . . . . . . . . . . . . . . . 2620 Example BCC calculation, Courtesy Control Techniques . . . . . 2821 Mentor II DC drive front panel . . . . . . . . . . . . . . . . . . . 2922 Mentor II serial cable connections. Control Techniques. . . . . . 3123 Tektronix TPS 2024 4 channel digital storage oscilloscope . . . . 3124 GDS-820C 2 channel digital storage oscilloscope . . . . . . . . . . 3325 GDS-820C serial cable connections. Courtesy GW Instek. . . . . 3426 Mentor II remote inputs . . . . . . . . . . . . . . . . . . . . . . . 3627 Feedback oscilloscopes . . . . . . . . . . . . . . . . . . . . . . . . 3728 Modified control loop . . . . . . . . . . . . . . . . . . . . . . . . . 38

vi


7/81

29 Power vs. Loading condition . . . . . . . . . . . . . . . . . . . . 43

30 Voltage vs. Generator power . . . . . . . . . . . . . . . . . . . . 4431 Current vs. Generator power . . . . . . . . . . . . . . . . . . . . 4532 Electrical frequency vs. Generator power . . . . . . . . . . . . . . 4633 Tip speed ratio vs. Generator power . . . . . . . . . . . . . . . . 4734 RPM vs Generator power . . . . . . . . . . . . . . . . . . . . . . 4835 Torque vs. Generator power . . . . . . . . . . . . . . . . . . . . . 4936 Step response to a load increase . . . . . . . . . . . . . . . . . . . 5037 Step response to a load decrease . . . . . . . . . . . . . . . . . . 50

vii


8/81

4 Introduction

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

The motivation for this project is to create an emulation system that asclosely as possible replicates the behaviour of a wind turbine in steady stateconditions, which will allow the testing of power electronic devices designed tomaximise the turbine power output. This emulation system removes the unpre-

dictability that goes with testing a turbine under real wind conditions and alsoremoves 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 ac-tually be better for testing power maximizers then the wind tunnel, as it wouldnot only work in steady state conditions, but in cases of varying wind as youwould see in a real installed turbine.

This thesis presents an emulation system that seeks to satisfy the above aimof replicating the behaviour of a real wind turbine for the purposes of creatinga convenient test set to be used to test wind turbine power maximizers. Theconsruction 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.

1


9/81

5 Wind Power

5.1 Outline

In this section, the characteristics of wind pertinent to energy conversion will bepresented; followed by an introduction to wind energy conversion systems. Theequations governing such systems, their components and performance charac-teristics will be described in detail.

5.2 Wind energy

The natural motion of air in the atmosphere, wind, is caused by pressure differ-ences across the surface of the earth do to the uneven heating via solar radiation(3, pp. 22). From studies of fluid mechanics, this flow of air can be analyzed as

mass flow with kinetic energy given by:dmdt

= AUEk =

12mv2

Pk =12AU3

(1)

Where A is the area of the incident air stream, U and the velocity anddensity of the flow respectively. Generally, A, the stream area of interestis 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 arotation of the WECS rotor, with a maximum possible efficiency of 59 .26%,referred to as Betz limit. The derivation of this value is beyond the scope ofthis introduction, however it may be found in (3, pp. 87). Furthermore, it canbe 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:

Pk =1

2R2U3 (2)

That a twofold increase in the radius if a WECS blade geometry results in afourfold increase in captured energy.

5.3 Wind energy conversion systems

To date, there have been a variety of WECS designs; however by far the mostpopular and widely used is the horizontal axis wind turbine (HAWT). As madeclear in the Introduction, the design of interest is the low-cost, low-power HAWTdesign common in rural and urban applications. Such systems are becomingincreasingly 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 whichthe blades are mounted. The performance of a wind turbine is greatlyaffected by blade geometry, and in many designs, this component is alsothe most expensive part of the turbine unit.

Drive train Connecting the rotor to the generator is the drive train. In larger windturbine systems, the drive train includes gearing to increase the speed ofrotation from the rotor into the generator. Small turbines do not havethis feature, the drive train for these systems is simply a connecting shaft.

2


10/81

Generator The generator converts the mechanical rotation of the drive train into elec-

tricity. Small turbine generators are commonly of the 3-phase, permanentmagnet type; however other generator types have been used.

Controller To protect the system, in addition to converting the output of the gener-ator to domestic voltages, a power electronic interface converter is neces-sary.

As noted, the performance of a turbine is greatly affected by geometry. Charac-terizing this performance is commonly done with a CP- curve; a plot of powercoefficient to the tip speed ratio of the blades. The power coefficient CP denotesthe efficiency of the blades in extracting the power in the wind, whilst the tipspeed ratio (TSR) is the ratio of the speed of the blade tips to the air stream.The relationship is found as follows:

CP =PTPk

=2PTAV3

(3)

Thus, CP is the fraction of power that is transferred from the wind to theturbine blades (4). As previously mentioned, the theoretical limit for this isapproximately 59.3%. This term can be modified to then find the torque in Nmof the rotor that the wind induces (3, pp.164):

Q = CQ12R3U2

CQ =CP

(4)

Where CQ is the torque in Nm developed by the rotor, and calculated asper 8.

Of particular interest is the low power systems outlined in the introduc-tion. These systems have a much wider application, from powering remoteemergency telephones to powering outback water pumps. As such, technologyimprovements in these systems can lead to a large increase in renewable elec-tricity generation.

3


11/81

Figure 1: A small HAWT. (1)

An example of these systems is shown above, and are commonly used tocharge batteries. Such a system allows electricity to be drawn without theturbine 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 amore specific way. An example of these systems, (2) and (5), can be found touse lower rated DC motor sets and dedicated computer hardware systems.Such systems maintain only a limited control over the system and are unable toprovide the operator with a highly flexible environment to rapidly iterate theemulation system over a variety of user defined operations.

4


12/81

Figure 2: Emulation system from (2)

One such system is shown above, and limits the operator of the system tofeeding in a wind profile before execution. Such a system does not allow the

user to control the wind speed directly, or view various system variables on thesimulation PC as the execution platform is a separate Daq board. It thereforedesirable to find a more general solution to the emulation of such systems inorder 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 governthe performance of a wind turbine. The conversion of kinetic energy to rotorenergy was explored and previous simulation systems were presented. The sys-tems that have been used to replicate these turbines was explored and theirshortfalls mentioned. Finally, the general solution to emulating these systemsis introduced as a focus for the remaining sections.

5


13/81

6 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 predictthe output voltage, current and power of the generator for any given speed. Inorder to be able to predict the output, Matthew has used the RPM, the opencircuit 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 resistanceR and internal inductance L of the generator, the derivation of which will beshown later in this section.

Figure 3: Generator equivalent circuit

Using the following equation the output voltage and current can be predictedwithin 40% at very low speeds and to within 10% at higher speeds.

|V t| = ERT

R2T

+ (L)2RL

2

+E L

R2T

+ (L)2RL

2

(5)

Above is the voltage at the load terminals. A similar expression gives thecurrent through the load;

|It| =

ERTR2T + (L)

2

2+

E L

R2T + (L)2

2(6)

In the following equation the following terms are used;

E = Generator back-emf

= Angular Speed = 2 (RPM/15)

6


14/81

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 knowncurrents are fed into the generator and the resistance is then calculated usingOhms Law, while a simple digital multimeter can be used at zero current. Thenusing a star equivalent model of the generator the internal resistance then be-come 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 eachphase was first found by manually turning the shaft in 20deg increments todetermine the minimum and maximum values of inductance of each phase. Asbefore using a star equivalent model of the generator means the internal induc-tance is then halved to give a value of 2.358mH.

A model of the 300W wind turbine generator was developed that gave theability 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 alsolater in the emulation systems feedback to enable calculation and comparisonof the output torque with the required torque.

7


15/81

7 Aerofoil characteristics

James Derricott

7.1 Overview

When an aerofoil is being subjected to a stream of air, be it on an airplane, orwind turbine or any other application, the aerofoil produces a lift force as a re-sult of differential pressures on the aerofoil sections. This differential pressure isa result of the air stream moving over and below the blade at different velocitiesthanks to the shape of the blade. In the case of a wind turbine this lift forceproduces 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 flow. This uniformity is disruptedat the tip of the aerofoil, when instead of flowing smoothly over and below theaerofoil section it swirls out from the tip. This reduces the efficiency of theaerofoil as most lift and power is produced closest to the tip.

In order to determine if this tip loss is significant for this turbine the aerofoilblade was tested using a specially conducted test rig in a 1 by 1 meter windtunnel at Monash University.

As well as investigating tip loss, the aim was to also produced a CP curvethat could be compared to the curve determined in the wind tunnel.

8


16/81

7.2 Tip loss

In this subsection a comparison is presented between the lift forces on an aero-foil section with and without end effects plates. The end effect is a term usedto describe the loss of efficiency that an aerofoil section experiences near its endtips. This effect is cause by the air swirling around the tip in a non-uniformfashion, thereby reducing the effectiveness of the tip of the blade - a section ofthe aerofoil with which most power is produced.

Figure 5: Aerofoil Testing Rig

The apparatus used to test this effect can be seen in the above figure. Byadding plates of aluminum to the ends of the aerofoil it in affect forces the air toflow past the tip in a uniform fashion, thereby eliminating the swirling aroundthe tip that is characteristic of the end effect, and assumably making the wholesection more efficient in producing lift.

9


17/81

Figure 7: Lift vs angle with endplates

In the above figures, we can see the difference in lift force experienced bythe aerofoil is impacted by the presence of the end effects plates, which help toeliminate the loss of power from the swirling affects 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 efficiency of the blade will alsoimprove.

Figure 8: Drag vs angle with no endplates

10


18/81

Figure 9: Drag vs angle with endplates

Having the end effects plates present on the aerofoil appears to increase thedrag slightly at higher angles, meaning a slight reduction in blade performancemay result.

11


19/81

7.3 Cp curve comparisonThe Lift and Angle data of the aerofoil taken from the wind tunnel measure-ments can be used to calculate the CP curve which can be compared to thecurve obtained by testing the whole turbine in the wind tunnel. The algorithmfor doing so is explained below, but for the full code it is suggested the readerlook at Appendix B: Aerofoil Testing Code.

The testing of the aerofoil was done at 13.4m/s wind speed, while the testingof the wind turbine was done at 9m/s. There was no time to complete furthertesting of the aerofoil at 9m/s, but there should not be an issue with compar-ing the two Cp curves as the wind speed should have no effect on the final 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 ef-fective velocity is calculated for each blade element, which then enables thecalculation of each blade elements angle with respect to the wind.

Each blade element produces a different amount of lift depending on its an-gle. To find the lift that each blade element produces, the angle of that bladeelement 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 sameangle in the wind tunnel (although scaled by 100 blade elements).

The torque for each element is then found by multiplying that lift by thelength of the element, and then summing them up to give the total torque forthe aerofoil section. This total torque multiplied by the number of blades givesthe torque produced by the complete rotor. The power is then the total torquefor the rotor multiplied by the angular speed .

The CP is then calculated using;

CP =P

12R2V3

(7)

And then the TSR;

=R Vwind

(8)

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

12


20/81

Figure 10: Cp-TSR curve WITH endplates

This comparison can be done with or without endplates. In practice it wouldseem intuitive that only one end plates would be necessary to correctly calculatethe CP-TSR curve.

Figure 11: Cp-TSR curve WITHOUT endplates

These curves approximate the Cp-TSR curve measured for the wind turbine

13


21/81

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 explanationfor this is not available at this time.

Figure 12: Cp-TSR curve comparison

The above figure shows a comparison between the curves obtained for theaerofoil with and without endplates (blue and green respectively) and betweenthe curve obtained from experimental data in the wind turbine. It is immedi-ately obvious that the curve for the aerofoil is no longer valid after a TSR of 6,but before that offers a comparable result.

7.4 Summary

Using data obtained from testing a 300W wind turbine in a large wind tunnel, aCp-TSR curve was found. Then using the same aerofoil blades in a smaller windtunnel, lift forces on the blade were measured through various angles. These

were measured with and without aluminum plates on the ends of the blade todetermine the effects of tip loss on performance. The data obtained from thesetests was used to determine the theoretical Cp-TSR curve which is directly com-parable 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 effect at thisstage and would be a subject of further investigation if time would allow.

However below a TSR of 6 the comparison results are considered valid anddemonstrate the relationship of the blade aerodynamics to the Cp-TSR curve.

14


22/81

15


23/81

8 Steady State Testing

James Derricott

8.1 Overview

In the following section the reader is introduced to the topic of steady statetesting, which is necessary to determine the performance of the wind turbineunder various conditions, such as different wind and loading conditions. Test-ing of the turbine in the wind tunnel, combined with a model of the turbinegenerator, yields a result for the Cp-TSR curve, which can then be used in theimplementation of the emulation system.

8.2 Wind tunnel

In order to determine the steady state performance that the emulation systemrequired, it was first necessary to determine our benchmark performance - i.ethe steady state performance of the wind turbine that was to be emulated. Thewind turbine and Cp data used int his section was made available thanks toPeter 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 meterswas used, in which was placed the low-power (300W) turbine and then run atnumerous steady state wind speeds and under various loading conditions. The

16


24/81

figure 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. ForAC loading conditions the generator output was connected to two three phaseload banks connected in delta, in order to provide a high loading condition asnecessary. The DC loading was done by first rectifying the AC output and thenusing a 12V battery as the load, which replicates the real intended loading forthis type of wind turbine.

Using the results obtained from each type of loading, including variations indirection 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 CPTSR curve was obtained usingthe results of the wind tunnel testing.

The equation to obtain the Cp-TSR curve from the wind tunnel data isshown below;

CP =P

12R2V3 (9)

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 RRPM/60V (10)

Which can be seen is the ratio of the speed of the tip to the speed of the incom-ing wind.

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

17


25/81

calculate the Blade Power as follows;

P = BladeTorque 2 RPM/60 (11)

The Blade Torque is found using the generator model equation below;

BladeTorque =

Where PRC refers to P + Rectifier Loss + Converter loss, the power outputin addition to the losses in the rectifier and converter, which are only applica-ble the the load is being rectified and fed into a DC load rather than an AC load.

PRC=

3

VACrmsIACrms

3 + VDCIDC + IDC 1.5 2 + 0.1 I2

DC (13)

Where;

3 VACrmsIACrms3

VDCIDC

is the power output of the generator,

IDC 1.5 2is the Rectifier Loss, and

0.1 I2DCis the Converter Loss.

Figure 14: Experimental Cp-TSR Curve

18


26/81

The above CP curve shows that the 300W wind turbine tested is notterribly efficient, with the maximum CP of 0.22 being well below the Betz limitof 0.59

8.4 Summary

The past section has outlined the use of the Monash University wind tunnel intesting the steady state behaviors of a 300W wind turbine under different windspeed and different loading conditions including three phase AC loading andDC loading with a rectifier and battery arrangement.

The data measured from the wind tunnel was used with the generator model

to find the Cp-TSR curve, which was used directly in the emulation systemwhich is discussed later and also used as a comparison with the data collectedfrom the aerofoil testing to make a comparison between the Cp-TSR curves fromthe previous section.

19


27/81


28/81

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 currentspeed of the DC motor back to the PC, which is then used to calculate the TipSpeed Ratio.

The drive uses this torque command to control the DC motor. The DCmotor used is a separately excited DC machine rated at 30kW, which is beingused as the prime mover for the emulation system, which means that it is pro-viding the torque and power to rotate the shaft that would have otherwise havebeen provided by the wind. In order to write torque commands to the drive,a commanded torque in Nm must first be scaled to a value from 0 to 100% offull-rated torque that the drive is capable of applying. To measure this scalingfactor a lebow torque transducer was used as well as a signal conditioner cali-brated 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 writtento the drive until an equilibrium was established, thus giving a scaling factorbetween real torque in Nm and % full-rated.

The DC motor is then connected to a permanent magnet induction gener-ator rated at 300W continuous output power, which was taken directly out ofthe real wind turbine that this project is emulating.

After the generator the three phase output can be used with different loads,as a three phase output or rectified and used to charge a 12V battery. Theoutput voltage and current from the generator is also used by the system asa 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 separatedigital oscilloscopes are used, each with the ability to communicate to the PCvia a serial cable. This provides a closed-loop system which can eliminate steadystate errors in the emulation of the turbine.

9.3 Emulation software

Bryan Hanson

The software platform selected for the simulation is The Mathworks productMATLAB, in addition to the Simulink modeling package. MATLAB, a numer-

ical computing environment, was selected as it presented significant benefitsover the more traditional microprocessor approach; as a more general solutionto wind turbine emulation was sought. The main features required in the emu-lation system were as follows:

Modularity Wind turbine design is an innovative field, with new designs introducedon a regular basis. Testing these designs for regional wind performance orspecific conditions such as gusting currently requires the purchase and testof the units in large wind tunnels. The ability to experiment with differentdesigns on the test system without requiring fundamental modificationsto the solution would allow for new technology in wind turbines to be

21


29/81

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 appliesfor system modification; various wind regimes and turbine characteristicscan be altered or replaced by the operator with ease. This allows thesystem to be used by a greater number of people, including those withoutavailable resources to test turbine designs in a wind tunnel.

Time critical Hardware-in-the-loop simulation requires timely calculations, the systemneeds to react in a realistic manner to load variations applied by theturbine controller. Under steady state conditions, this requirement maybe relaxed; controller performance is generally calculated as an overallefficiency irrespective of dynamic behavior.

All of these requirements can be met by MATLAB, in addition to offering thefacility of porting the simulation system to a variety of different hardware plat-forms and architectures. Each of these features will be covered in detail in thefollowing 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 programmedin the MATLAB programming language, called m-files. These files contain thecommands used by the simulation to initialize itself and communicate with thesystem hardware. As such, the system lends itself easily to modification, andcan quickly be ported to work with system hardware other than that defined

above.

In addition to this, characteristics of the turbine to be modeled are containedwithin separate files loaded by the initialization script. This design allows tur-bine characteristics to be modified quickly, as the variables are not encodedinto the simulation itself. This includes the CQ- curve and various propertiesof the turbine and simulated environment including blade radius and air density.

The user may also easily extend the scope of the simulation platform, suchas integrating the CQ- curve as the output of a series of aerofoil geometryanalysis scripts. This allows the simulation platform to perform a more generalemulation 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 layouteditor Guide. This allows user friendly interfaces to be designed to operatethe simulation using familiar controls such as check boxes, sliders and pull-downmenus. Due to the tight integration with the MATLAB suite, these user inter-faces may display or control any simulation variables used by the simulationmodel, in addition to modifying a subset of these during execution.

22


30/81

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 thesimulation. This extends to the modification of data logging, as the use maychoose to record any time varying values, such as generator voltage, to a separatefile to be exported into a variety of formats or plotted against other variablessuch as wind speed.

Figure 16: Measurements & plotting capabilities

As such, the simulation environment may be tailored to the users require-ments quickly and easily, to facilitate focus on either specific aspects of thesystem such as the controller algorithm behavior in over speed conditions or

as general as the steady state efficiency of the rectification stage of the powerelectronic 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 simula-tion execution and shows the position of the system on the curve in red. Thiscustom function is a convenient method for the operator to visually inspect thecurrent efficiency of the system and the effect of load variations from the powerinterface converter. Naturally, this plotting function may be modified to displaythe CP-, or any other values if the operator so desires.

23


31/81

Figure 17: Live CQ- curve plotting

9.3.3 Execution

As the simulation system is not a fully developed product, the current executionof the system limits it turbine simulation behavior to steady state conditions.This is in part due to the currently used method of simulation execution, anon-deterministic soft real-time execution on the Microsoft Windows XP op-erating system on a consumer PC. This platform is not ideally suited to real-timecapabilities and thus prevents the system from executing at a simulation speed1 to 1 with reality.

This results in behavior that does not match that of a real turbine withregard to the timing of events. An example of this phenomenon is the timetaken for the simulation to begin from a standstill to reach steady state if aneffective step change of wind speed is applied. The time for this to occur willnot necessarily be the same as that of the real turbine; and while it may bepossible to tune the simulation execution parameters to ensure this occurs, itmay not hold for different values of step changes.

However, the simulation has the potential to execute in real time through avariety of methods. The first and most convenient is the use of the real-timetarget for Windows, a product from The Mathworks that enables Simulink tooperate in real time. In addition to this, the simulation may be ported to aplatform where kernel mode execution will result in deterministic operation;such as a Real-Time Operating System (RTOS), through the use of MATLABsReal-Time Workshop. This results in the Simulink model being compiled intoC code for portability to a wide range of platforms and architectures, includingembedded systems.

24


32/81

9.3.4 Schematic

As previously mentioned, the simulation itself is programmed in the block di-agramming environment of Simulink, connected to MATLAB and the systemhardware using script files. This programming paradigm allows the simulationto be graphically built from a series of blocks that perform a specific task, whichwill each be introduced and explained below.

Figure 18: Simulation model

The above image shows the full simulation. It may be viewed in detail underappendix 13.8. Below shows the core simulation section of the model:

25


33/81

Figure 19: Core turbine simulation

Beginning from left to right, the simulation executes sequentially, fromsource to sink block. This process is iterated over the desired time period usingthe operator defined 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 gen-erator from the DC drive over the serial communications link. This, cou-pled with the user defined wind speed input to the system at the currenttime 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 foundusing a lookup table. This table is user defined and may be modified bythe operator to simulate different turbines. CQ lookup is performed usinginterpolation and so the curve may be defined using a loose set of points.

Aerodynamic torque The simulation then continues by calculating the aerodynamic torque ofthe blades exerted on the generator given the current conditions. Thiscalculation, 4, as follows:

Q = CQ12R3U2

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

9.4 Serial communication

Bryan Hanson

26


34/81

Communication with the hardware components previously introduced in ??

occurs over RS-232 serial channels. Each peripheral involved in direct commu-nication with the simulation PC occupies a D-subminiature 9 pin COM portwith a cable to suit its unique requirements. In addition to this, each device re-quires a separate series of commands to operate, each of which will be discussedon a device by device basis below, following an introduction into the RS-232communication standard.

9.4.1 RS-232

The RS-232 serial communication standard defines the transfer of binary databetween 2 devices. In the original standard, the intended topography of the net-work at the time were end instruments connected via a modem. This resulted in

the standard defining communication between Data Terminal Equipment (DTE)end instruments and Data Circuit-terminating Equipment (DCE) modems. Inaddition to this, communication between devices was coordinated with flow con-trol signals, so that devices would not attempt to transfer binary data at thesame time.

RS-232 communication between devices used for the simulation system arearranged for direct communication to the simulation PC, that is DTE-DTE,and do not use flow control to coordinate the transfer of information betweenthem. Each of the devices additionally defines the wiring of the cables that con-nect them to the simulation PC, however the transmit and receive lines remainthe same for all devices. This permits the use of MATLABs standard functioncalls 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 pa-rameters to each device individually. Each of the devices may be individuallyaddressed for these operations as the read and write functions are passed the se-rial object to interact with, of which any number of serial objects can be created.

During execution of the simulation, where read-writes are performed manytimes a second, it was deemed that error checking would not be performed. Thisapproach has proved to be working arrangement, and only one issue with thishas arisen. As the reads and writes are blind, if the serial operation returns anerror, such as a timeout occurring because a message terminator was not re-ceived, the simulation will halt. This behavior is highly undesirable, and mostlyunpredictable, occurring mainly with the Mentor drive under high CPU loads.

With regard to the speed of the RS-232 communications links, it was decidedthat 9600 Baud would be sufficient to transmit the short messages between thedifferent peripherals. If future expansion of the system results in inter-devicecommunications exceeding this speed, the RS-232 standard defines speeds thatare considerably greater than that chosen, and the serial object creation sectionof the initialization script may be modified to reflect this change.

The parameters of interest for each peripheral follows below, including thenature of the commands they accept and additional capabilities they give theoperator for expansion of the system.

27


35/81

9.4.2 Mentor II Communications

The Mentor II DC drive uses a unique set of communication commands thatpermit many of the settings and parameters of the drive to be modified whilstthe drive is in operation. For the purposes of the simulation the only parametersthat are accessed is the torque reference, used to vary the torque at the gener-ator through the DC motor, and the speed of the shaft, used for calculation ofthe tip speed ratio described in ??.

Communication with the drive however, requires a series of parameter mod-ifications to disable the operation of the front panel of the drive, as well as aunique communication checksum requirement for each command. This check-sum, referred to in the drive literature as the BCC, is required at the end ofevery command, and is calculated in the following fashion:

1. A progressive binary XOR is performed on all characters of the messageafter the start-of-text command parameter.

2. The final XOR is the BCC if it exceeds 31, otherwise 32 is added.

An example BCC calculation, extracted from the Mentor II User Manual, isshown 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 cal-

culation, are comprised of a series of ASCII literal and control characters. Thegeneral structure of these messages, from the Mentor II User Guide, are as fol-lows:Sending data

reset

address

start-of-text

menu + parameter

1 to 5 data characters

end

BCC

28


36/81

Requesting data

resetaddress

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 charactersfrom the response automatically, however no error checking using the BCC isperformed.

Figure 21: Mentor II DC drive front panel

Using this method, drive parameters that a writable may be modified, how-ever as the drive has been modified to accommodate local control via a front

29


37/81

panel 21, the parameters of the drive that are manipulated via serial communi-

cation will be overwritten by the input of these controls. As such, these controlsmust be deactivated by modifying the destination of these inputs to drive in-valid parameters. This will then allow the simulation to freely modify valuessuch as the torque reference without being overwritten. The parameters thatare modified for this purpose are as follows:Set general purpose input 4 (GP4) destination, the analog torque reference con-trol, 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 thenfollowed by writing the following parameters to the drive, show without controlcode 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 ofthe following parameters of interest:

0408

This parameter, the DC motor torque demand, is driven by the output of thesimulation, to reflect 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 persecond.

Connection to the drive for the communication described above requires anon standard wiring of the serial cable. The cable used for the system was handsoldered for this purpose and uses the following connections:

30


38/81

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 thefeedback oscilloscopes whose purpose is outlined in ??. Communication with

this device occurs over a standard null modem cable, used to connect two DTEdevices together as defined in the RS-232 standard. This is the only device usedin 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 de-vice programmer manual, which allows all device functions to be used remotely.The functions of interest to the simulation are related to reading in the rootmean 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 notused to read in any other measurements by the simulation. The reasoning be-hind this choice is a result of the update speed of the traditional measurements

31


39/81

taken by the oscilloscope and displayed on its screen. These values are updated

slowly, and measured infrequently, a characteristic that makes their use unsuit-able for use in the simulation.

There is included another, superior method of retrieving measurements fromthe oscilloscope in the form of immediate measurements. These measurementshave no local equivalent, and are only available as a remote option. Values readby 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 sufficient to cause instabilityin the controller

To use the immediate measurement facility, the following commands mustfirst 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 imme-diate measurement source to channel 1 (CH1) and set the measurement valueto be the cyclic RMS (CRMS). Once the oscilloscope has been configure forimmediate measurements, the following command may be issued to retrieve thecurrent RMS value:

MEASU:IMM:VAL

Issuing this command in too rapid a succession will cause the oscilloscope tobecome unresponsive to local user input, however it will still respond with im-mediate measurement values. However, if the rate of requests increases abovethis threshold, the oscilloscope will respond with an error. It should be notedthat 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 oscilloscopesplay in the simulation, the operator is free to use the remaining channels ofbot test instruments to take further readings, without affecting the serial datatransfers. This allows the operator to perform a variety of other measurements,including use of the MATH functions of both instruments to monitor voltagesand currents of additional equipment.

9.4.4 GW Instek GDX-820C

The final system peripheral that communicates via serial to the simulation PCis the GW Instek GDS-820C oscilloscope, a 2 channel digital storage oscillo-scope that is used to circumvent the issue of measurement readings from theTektronix oscilloscope. As only a single source may be selected for these im-mediate measurements, a second oscilloscope is used to acquire readings of thesecond value of interest 9.5.3.

32


40/81

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

Unlike the Tektronix oscilloscope, there is only a single method of request-ing values from the GW Instek; via a command referred to in the productsprogrammer manual as MEASURE. This command, similar to the immediate

measurements of the Tektronic oscilloscope, may only be active on a single chan-nel for a single measurement at any one time. The commands used to place theoscilloscope in this mode are as follows:

:MEAS:SOUR 1

This places the oscilloscope measurement mode on channel 1 (CH1). The oscil-loscope 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 usermanual, is wired as follows:

33


41/81

Figure 25: GDS-820C serial cable connections. Courtesy GW Instek.

Both GW Instek and Tektronix oscilloscopes respond to requests of measure-ment values with an ASCII string in scientific notation, and is automatically

converted to a number in the simulation. If verbose mode on either oscilloscopehas been activated, an error will occur as there is no input sanitisation in theserial 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 desirablefor the emulation system to be as realistic as can be achieved. This sectiondiscusses some important considerations such as friction and running torque ofa shaft, and how these things contribute to the performance of the system. Itpresents 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 mustfirst overcome a friction which is holding it in equilibrium. This force, termedthe stiction, will hold the shaft motionless until enough torque is applied tothe shaft for rotation to begin. Once the shaft has started to rotate less torquewill be required to keep it turning then the original starting torque that wasnecessary to overcome the static friction.

The static friction is found and given a value by determining exactly howmuch torque is required to just begin the shaft rotating.Once this is determined it is possible to compensate for this effect by initially

writing this extra amount to the drive, on top of the normal required amountgiven the set conditions, and hence this extra amount of torque will then over-come the friction and the shaft will then see the required torque and the frictionwill be effectively canceled out.

It should be noted that shaft friction, be it static or running (to be discussedlater), will be changed depending on the loading conditions of the shaft, so inpractice for compensation to work effectively in this fashion, the friction torque

34


42/81

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 staticfriction compensation factor at zero drive speeds, until rotation is detected, forwind speeds above cut-in.

It was initially decided to use an additional amount of torque in the case of azero RPM when there was any input to the simulation (that is, wind), howeverthis proved unsatisfactory as a non-zero RPM would be generated, disabling theadditional torque amount added and cause the drive to stall. This was becausethere was a torque required to be added to the drive at all times in order tokeep it rotating at the desired reference. This is the running torque, which isdiscussed 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 valueneeds 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 re-verting 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. Run-ning torque is a friction torque that resists the applied torque while the motoris running. Running torque exists all all speeds but is not a constant value overthe whole speed range, ranging from between 1 Nm at low speeds to almost 3Nm as higher running speeds.

In order to compensate for running torque it is necessary to write the run-ning torque in addition to the current torque demanded. The simplest way todo this is to assume a constant value of running torque over the entire speedrange. As the running torque is dramatically different over a wide speed rangethis is not a good approximation.

A more effective use of the same strategy is to break the operation speedsinto a number of ranges. Over these ranges it is assumed that the runningtorque is constant, and a lookup table can be used so that depending on the

speed range the adThis table used a speed input and would output the additional amount of

torque needed by the drive to simply rotate. Experimentally deriving this torquecurve proved difficult, and was not repeatable. This is due to the large numberof influences the running torque was affected by. One of the main influences wasthe duration of time the drive had been operational, as this seemed to warm upthe bearings and as a result changed the running torque, meaning that extendedperiods of operation were seen to cause a decrease in the amount of additionaltorque required to keep the drive rotating. At this point it was decided to pursuean active compensation scheme utilising feedback that was capable of adaptingto the varying running torque.

35


43/81

9.5.3 Active Compensation

Bryan Hanson

Active compensation is a method of combating the various loss mechanismsof the prime mover by using closed loop control on the feed forward torque de-mand. As the simulation calculates the generated blade torque, simply writingthis demand to the DC drive will result in poor simulation accuracy. This is be-cause the losses will reduce this torque to a lower value at the input shaft of thegenerator, which in turn, affects the rotational speed of the shaft, and resultsin the simulation stabilizing at a different point on the CQ- curve. The onlyway of ensuring that the generator receives the correct torque is to offset thelosses with additional torque, ensuring that the desired torque at the generatoris that which is desired.

As finding the correct losses in any situation proved problematic, as detailedabove, a unique approach was devised; by using the generator model previouslyderived for steady state testing, the mechanical torque on the generator couldbe calculated. Once the torque at the generator can be found, it becomes amatter of varying the torque demand to the DC drive above that calculated bythe simulation until they are equal. This additional torque written to the driveis the torque loss of the system, and need not be calculated, only offset.

The generator model, introduced previously in section 6, requires the RMScurrent, line-to-line RMS voltage and shaft speed of the generator to calculatetorque; values which would need to be taken at regular intervals with a reason-ably 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 theDC motor, taken from an installed tachometer. As communication with thedrive had already been established at this time; it became the obvious choicefor providing the generator shaft speed.

An investigation into acquiring the remaining measurements was performed,and it was found that existing equipment, a current and differential voltageprobe, could be used to extract the time varying signals required for furtherprocessing. The conversion of these AC signals to an RMS value was initiallyproposed to occur inside the simulation, by connecting the outputs of the twoprobes into the Mentor II drive for reading by the simulation PC.

Figure 26: Mentor II remote inputs

36


44/81

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 driveterminal block. Whilst both probes could have their attenuation adjusted to fallwithin the -10 to +10 voltage range of the analog input; the issue of reading thein the time varying AC into the simulation to extract the RMS value becameproblematic. The analog to digital conversion of the AC waveform, coupled withthe latency of the serial communication link and simulation update frequencyresulted in a waveform read by the PC that was not recognizable as AC. Assuch, the accurate extraction of the RMS value of both current and voltage ofthe generator output not found to be possible using this method.

After a brief consideration of using RMS to DC converter chips to performthe AC to RMS calculation before the signals reach the drive, an inspection ofavailable oscilloscopes found that RS-232 interfaces were present on a number

of units. As these instruments were capable of calculating the RMS of a signalwith high precision, and could communicate directly with the simulation PCover the same communications standard, it was decided to use this method toacquire the RMS measurements required by the generator model.

Figure 27: Feedback oscilloscopes

Whilst the use of 2 oscilloscopes is clarified in further detail in the serialcommunication section, 9.4, ultimately the function of these instruments is tocommunicate the RMS current and line-to-line voltage of the generator to thesimulation PC. Here, the values are used to calculate the torque at the genera-tor as per the model introduced previously in section 6, providing the feedbacksignal for a controller.

37


45/81

Initially, it was sought to use the Mentor II drive as the controller to accom-

plish this task; as the drive maintains robust internal control loops and wouldreduce the computational requirements of the PC for each simulation step. Aninvestigation into this prospect found that whilst there was a current feedbackparameter that could in theory be used to control the current demand to themotor, it was a read only value derived from internal current transformers. Thiswas due to the role this measurement played in initiating drive and motor pro-tection procedures, well as providing the drive operator with an indication ofarmature current.

Once this limitation was discovered, control from within the simulation wasinvestigated; using control blocks included in MATLABs library. Subsequentexperimentation with a variety of controllers led to the choice of a discrete PIto 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 it-erative fashion beginning with the proportional gain term, Kp. This value wasincreased incrementally in steps of 0.1 from 0 until the system became unsta-ble; exhibiting oscillatory behavior. The largest stable Kp was then chosen asthe proportional gain term of the controller, where the integral gain Ki is thenincremented in a similar fashion to reduce the steady state error to zero.

In addition to tuning the PI controller, experimentation with changing therate of controller execution in the simulation was found to have an improvementon rise time without an increase in Kp; however this line of modification was

not pursued far due to time constraints.

Due to the soft execution nature of the simulation, changing the computa-tional requirements of the simulation steps by either adding or removing calcu-lations will require a re tune of the PI controller. This requirement would mostlikely be relaxed if a suitable hard real-time execution target were used, optionsof which are detailed in section 9.3.3.

Due to the nature of the compensation, the blade torque calculated by thesystem will always result in a lower value at the generator if written directly tothe DC drive. This characteristic allowed a modification to the control loop toalways write the calculated torque to the DC drive, in addition to the controlaction provided by the PI:

Figure 28: Modified control loop

38


46/81

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 largeheavy object would have a high inertia, or alternatively an object with its massspread 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, whichhas mass distributed along the blade radius which increases its inertia.

In the emulation hardware, a large 30kW DC motor is being used, and due toits size has a large inertia which resists its ability to change speeds very quickly.This is offset by the large current (and therefore torque) that the drive can useto accelerate, with torque being related to acceleration via the formula;

T = I (15)

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 tolimit the rate of change of acceleration of the DC motor to match that that thereal turbine would achieve in practice.

In order to calculate the inertia the DC motor was run to 1000rpm and thenturned off and allowed to run down to zero speed, while the time to do so wasrecorded. This was also done with the generator which was then disconnectedand timed. The inertia for the whole DC motor and generator system was foundto be 0.864Nms2/rad, while the inertia of the whole wind turbine was found

to be 1.81Nm2/rad. This is not a surprising result due to much of the windturbines mass being spread out at a further distance from the rotor axis due tothe blades.

If used in the emulation system the inertia will provide a way of determiningthe acceleration of the system, which can be matched to the real turbine tomake the emulation respond more accurately. In effect the term will slow theemulation system down, as the extra inertia required to match reality will slowthe acceleration down and it will be necessary to write the torque required as aramping value of torque, with the ramp slope limited by the reduced accelerationof the system.

39


47/81

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 alsothe drive speed and simulation time step (note that the emulation system wouldhave to be run in real-time using the real time target for windows). The rampwould have a gradient limited by the calculated acceleration term, with thestarting value being defined simply by the current value of torque (before anysystem change, i.e pre- speed change), and would ramp up as defined by theacceleration (use the derivative block in simulink to take the derivative of thespeed) until it reached the maximum limit as set by the new calculated valueof torque. The simple delay and rate limiting blocks provided by Simulink willnot be sufficient here as the ramp rate (acceleration) will need to change dy-namically based on the change in speed. The controller will need to be retunedfor this as its performance is affected by the simulation speed.

9.7 Summary

In emulating the wind turbine it was necessary to use a number of differentelements to achieve this aim. Starting from the 300W generator from the windturbine, a 30kW DC motor was used as the prime mover to replicate the speedand 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 turnwas controlled by a PC running Matlab/Simulink. Feedback of voltage and cur-rent was provided from communication with digital oscilloscopes which enabledaccurate torque tracking.

The software model that calculates the behavior of the DC motor has beenprogrammed in MATLAB Simulink, executing in soft real time on a consumerPC running Windows XP. This system allows a great deal of flexibility for thesimulation 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. Com-munication between hardware peripherals to the PC occurs over RS-232 andinvolves the use of 3 serial connections; the DC drive and 2 oscilloscopes.

Active compensation using a PI controller uses measurements transmittedback to the simulation from these peripherals for closed loop control of the feedforward torque demand. The tuning of this controller was performed manuallyand exhibits acceptable transient response for the purpose of testing the steadystate characteristics of power interface converters attached to the generator.

Inertia affects the ability of the system to rapidly change from one torqueto another, in effect limiting the rate at which it can do so. The inertia of thewhole wind turbine was found to be much higher than that of the DC drive andgenerator system, due to much of the mass being spread out along the bladesrather than concentrated near the shaft as then DC motor is. This inertia effectwas never implemented in practise but it can be done by limiting the rate ofchange and by ensuring the system runs in real time. The cause of this wouldbe to slow down the DC motors response to changed in required torque (inputas wind speed changes) to match the response that the real wind turbine wouldhave.

40


48/81

41


49/81

10 System performance

by Bryan

10.1 Outline

This section will investigate the performance of the emulation system to ac-curatly replicate the behaviour of the simulated wind turbine. Performanceresults will be analysed and any issues that arose during testing procedureswill be noted. Following this, the dynamic performance of the system will bepresented, 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 per-formed by recreating the wind speed and loading conditions of the wind turbineperformance data collected from wind tunnel tests detailed in ??. Only perfor-mance data at a single wind speed, 9m

s, was collected for these tests; the full

results of which may be found in appendices ?? and ??.

The test procedure followed that of the steady state testing, 2 resistive loadbanks in delta supplied a variable load to the generator; with measurementstaken at steady state of the RMS current and line-to-line voltage. Additionally,measurements of various simulation quantities were recorded to show both theaccuracy simulation calculations and illustrate the effect of active compensation.

The terminology used in these results can be summarised as follows. Quanti-ties under the Simulation legend are those which were measured from resultsobtained on the emulation test rig, which is designed to replicate the results ofthe Experimental results collated from testing performed with the real turbinein the wind tunnel. Shown below are the results of these tests,

42


50/81

Figure 29: Power vs. Loading condition

The above figure shows the power generated by the simulation system testbench compared with that obtained from the steady state wind tunnel exper-iments. The simulation performs within an acceptable range of those valuesmeasured in the wind tunnel experiments, accurate enough to perform steadystate testing of power electronic interface converters outlined in the introduction.It should be noted that magnitude loading denotes increasing load imposedon the turbine by way of the load banks, being the number of switches toggled.

The following figure shows the voltage measurements taken for both thesimulation and wind tunnel experiments; note the Y axis scale begins at 20V,the error is not as large as it appears:

43


51/81

Figure 30: Voltage vs. Generator power

However, it can be observed that the voltage readings taken from the simu-lation are consistently lower than those from the wind tunnel tests. The mag-nitude of this difference is not large enough to negatively impact performancetesting of power converters attached to the generator and is therefore withinacceptable limits.

44


52/81

Figure 31: Current vs. Generator power

The current obtained from the simulation system follows the actual turbinequite closely; yet exhibits similar behavior to that of the voltage. As such,although there is room for improvement the margin is quite small.

45


53/81

Figure 32: Electrical frequency vs. Generator power

Electrical frequency measurements taken from the simulation system can beseen to converge at higher power levels, although the largest error that occursis at the no load condition and is only 0.5Hz or within 98% of the experimentalvalue from the wind tunnel tests.

46


54/81

Figure 33: Tip speed ratio vs. Generator power

TSR values obtained from the simulation rig appear to converge with theexperimental values obtained from the real turbine, however, similar to thefrequency the largest error is within acceptable limits for the intended usagescenarios.

47


55/81

Figure 34: RPM vs Generator power

The RPM measurements read from the drive can be seen to introduce anerror into the simulation; and appears to be less accurate than using the electri-cal frequency to derive the speed of the generator. Substituting the speed inputto the system for an oscilloscope reading was not performed, reasoning behindthis decision may be found in Section 9.4.

48


56/81

Figure 35: Torque vs. Generator power

As can be observed, the magnitude of additional torque required to compen-sate for losses in the system Compensation, varies with the operating condi-tion of the drive. In addition to this, the simulation blade torque is calculatedto 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 different points.

10.3 Dynamic performance

The dynamic performance of the system was not extensively tested, only thetransient response of the system to a series of rapid load and wind changes wasperformed. These tests were made as part of the controller testing outlined inSection 9.5.3, and represent the controller behaviour of the final

49


57/81

Figure 36: Step response to a load increase

It can be observed that the system overshoots the reference torque andoscillates slightly before obtaining a steady state error of zero. Note the largeamount of aliasing present in the system due to a combination of soft real timeexecution and latency resulting from serial communication. Below, the result ofa 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 comparisonto the load increase situation, however a steady state error exists for consider-ably longer.

Further dynamic performance testing was deemed inappropriate given the in-completeness of the system with respect to replicating the dynamic performanceof the turbine. This includes the lack of inertia modelling and the suboptimalcontrol detailed both above and in Section 9.5.3.

It should be noted however that at the time of writing, site data from aremote turbine installation was being prepared and collated for testing perfor-

50


58/81

mance of the simulation system.

10.4 Summary

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

51


59/81

11 Further work

In many projects there are extensions and further work that can be done tofurther improve and polish the final outcome.

Although this project has achieved all the original aims and goals there isstill further improvements and refinements that can be done to give a moreaccurate and more realistic result. Some of these ad

For completeness sake more investigation needs to be made of why the Cp-TSR curve predicted by the data measured using the aerofoil in the small windtunnel does not break and decrease past a TSR of 6. Up until 6 it appears closeenough to allow a comparison between the Cp-TSR curves from the aerofoil andthe turbine itself, but after a TSR of 6 the curve from the aerofoil keeps risingand 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 realisticthere are two main suggestions. To allow the system to emulated dynamic be-haviour of a wind turbine (i.e transient bahaviour as the turbine changes formone steady state wind condition to another), it is necessary to make the PI con-troller response a lot faster than it currently is. Currently the controller takesa very long time to achieve steady state performance with zero error, and tobecome dynamic it would need to be in the order of ten times faster. It is likelythat the delay in controller behaviours is closely tied with the speed at which thefeedback system operates. The feedback must interrogate the oscilloscopes forvoltage and current information and then use the generator model to determine

the torque before the controller can operate on the error signal. There may beother factors causing or contributing to the delay, and all possible cause wouldneed to be investigated.

The second recommendation to improve performance is to change the rate ofacceleration of the emulation system to match the real turbine. This is achievedusing the inertia of the wind turbine to limit the accelerating torque to achievethe 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 realtime which in Simulink uses hardware interrupts to ensure real time operation.

52


60/81

12 Conclusion

The aim of creating an emulation system was to facilitate testing of power elec-tronic devices for maximising the power output of a generator, in a controlledenvironment.

A low power wind turbine emulation system was constructed using a DCmotor as the prime mover, which was by a DC drive and a PC running Mat-lab/Simulink. This parallel simulation read in speed signals and used them tocalculate the Tip Speed Ratio and in turn the Torque Coefficient (CQ) whichwas used to calculate the required output torque for a given wind speed. Thistorque 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 requiredtorque and the actual torque at the generator, given by feeding back the volt-ages and currents into a model of the generator. This error was then controlledby a PI controller which forced the steady state error to zero. The speed of thecontroller was not enough to make the system capable of being able to accu-rately 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 behaviourof a low power wind turbine under steady state conditions.

53


61/81

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 witha 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, Designand 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 con-verters, in Electronic Design, Test and Applications, pp. 280284, 2002.

[6] M. Sacher, Characterisation of a low power wind turbine generator,2008/2009.

54


62/81

13 Appendices

55


63/81

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 vi-sualise 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 themotor-drive system.

Log on as user dghug with the password mosfet, or alternatively use an-other 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. Ensurethat you use 2007a and not 2007b.

Once you have started Matlab, change the current directory to dghugs doc-uments and then Matlab and finally to the Cq-turbine folder.

emulation of a low power wind turbine

Documents