I am trying to simulate a start-up event for the landbased NREL 5MW baseline wind turbine. For this purpose I adapted the NREL 5MW Baseline Controller following the advice given here: [url]START-UP]
More precisely I added a simple override pitch maneuver to the dll code (linear decrease of pitch angle from 90° to a low value depending on wind speed) and reformulated the torque controller a bit in the way that it not always computes the torque “as if it were in Region 3 whenever the previous blade-pitch-angle command was 1° or greater” (Otherwise it demands a negative torque when the generator is activated during start-up where the blade-pitch-angle generally is greater than 1°).
After the start-up procedure is finished I would like to let the baseline pitch-controller take over control over the pitch-angle. However, this does not work as expected. Instead the pitch angle is going crazy and starts to oscillate enormous at high amplitudes.
To debug the problem, I first tried to zero the integrator of the PI-Pitch-Controller at the time this controller become active, but that doesn’t help.
Then, I simplified the problem and just simulated the NREL 5MW wind turbine at steady wind (12 m/s) with
a) using the unchanged baseline pitch controller from the beginning of the simulation and
b) enable the unchanged baseline pitch controller only after 5 sec (TPCOn = 5 in ServoDyn).
Interestingly, here one can see a similar behaviour. If the pitch controller is used from the very beginning everything looks fine, but if the pitch controller is disabled for the first couple of seconds the pitch angle shows again high oscillations after activation (see attached figures).
Does someone have an idea what could be the reason for this behaviour? Is there anything else besides the integrator of the PI-Pitch-Controller one should reset before activating the pitch controller?
Additionally, I wonder about the values of the pitch angle which oscillate between -90° and +180°. As far as I understand, there is a pitch angle limit of [0°, 90°] set inside the controller dll and there is no pitch actuator dynamics modelled in OpenFAST (meaning the actual pitch angle is instantaneously set to the pitch command from the controller as described in this forum post: Drive-train model validation (Compared to FAST)). If that’s true, how could the pitch angle reach values beyond the limits of [0°, 90°]? Does someone have an idea?
My guess is the problem is a related to lack of proper initial conditions that keeps the controller from being initialized properly. When TPCOn = 0, you likely give the simulation reasonable initial conditions of rotor speed and blade-pitch angle, but when TPCOn = 5, the rotor likely overspeeds for a bit and when the controller is enabled 5-s in, the initial conditions to the controller are poor and it can’t recover. I’ve seen a similar problem if you set TPCOn = 0 and provide poor initial conditions on rotor speed or blade-pitch angle. More rigorous controls logic could probably be implemented to resolve this, but is not something I’ve looked into.
Regarding the blade pitch output exceeding the 0-90-deg range, my guess is this is related to the extrapolation of module-level inputs used within the software. BlPitch is an output of the ElastoDyn module, which time-integrates from n to n+1 before other modules, using extrapolated inputs (including blade-pitch) from ServoDyn to have inputs at n+1. If the input time history is not continuous, the extrapolation is poor. My guess is the controller is commanding large jumps in the pitch angle, resulting in a noncontinuous blade-pitch angle time history. You can reduce the effect of the extrapolation by adding correction steps (NumCrctn >0), but it is better to ensure that the controller outputs smooth (continuous) controller commands.
Yes, you are right, it seems to be related to the initial conditions. I thought about that before, but just wasn’t aware how sensitive the controller is on poor initial conditions. Animated by your post, I run a simulation with TPCOn = 0, a steady wind of 12 m/s and an initial rotor speed of 12.1 rpm - and everything went fine. However, even with a slight change of the initial rotor speed to e.g. 12.25 rpm, the pitch controller becomes unstable resulting in unreasonable pitch angles.
Thus, I agree, that implementing a more rigorous controls logic should resolve the issue. However, at the moment I am not shure, what exactly to change in the controller. Have to think about it a bit. If someone has an idea, anything is appreciated
Regarding the blade pitch output, you are right, too. After setting NumCrctn = 1, the blade pitch angle output doesn’t exceed the 0-90-deg range anymore. Thanks, for the explanation on the integration scheme and extrapolation. Something else that I’ve learned. That’s why I love this forum.
I’m curious if the ROSCO Toolbox-developed controller for the NREL 5-MW baseline wind turbine has a similar sensitivity to initial conditions: github.com/nrel/rosco? This is something I don’t know the answer to.
I recently read many papers using FAST simulation.They changed its control method and simulated it, using images to verify the superiority of the control method.The most used is test23, test24.There are some problems bothering me.
1）How should I change the control mode of the unit? 23 24 is different from 01. 01 gives a model. If I want to use 23 24 to simulate, do I need to build a model in simnlink? Still need to recompile S-Functiong or Discon file?
2）Like the image of the classmate above, how should I get such an image? Do I need to input the data in the output file into matlab and build an image?
Sorry for asking these idiotic questions, I am a little slow in my studies, looking forward to your reply
I’m sorry, but I’m not really sure I understand your questions. Just a couple comments:
You shouldn’t need to recompile the FAST library or FAST S-Function unless you want to change the FAST source code, which is not required if all you you want to change is the model properties (mass, stiffness, geometry) or controller. You will likely need to recompile the DISCON.dll if you are implementing a new controller in the DISCON.DLL, unless you are using standard features of the ROSCO toolbox. You can also implement controls in Simulink, or use some of the built-in control options.
Running FAST will generate time-series output files; you can post-process these in a number of ways, e.g. loading the data into MATLAB and plotting the time series there. NREL has provided several MATLAB-based post-processing tools if that is what you use and depending on what you want to do, e.g., the MATLAB Toolbox, MCrunch, MExtremes, and MLife.
Are there any python based tools released by NREL that is a substitute for MLife and MExtremes? I currently do not have a MATLAB license and I would be very grateful if you could let me know of any python based tool that can do what MLife does.
A Python-based version of the MATLAB-based post-processors MCrunch,MExtremes, and MLife has been initiated in tool called pCrunch (github.com/OpenFAST/python-toolbox, but there is not much there yet. I know there have been many more scripts written then are currently uploaded there. I would suggest raising the question on what the development plans are on their associated issues pages.
I have encountered similar issues on the design of a controller for a mid-size turbine, with the Pitch Command not being reflected in the Pitch output.
This is associated with a PitRate saturating. When I run SImulink and Sfunc with the same controller (as far as I can tell, including GenSpeed filter), however, I get a smooth output and a very acceptable behavior. Is there any difference in handling InterpOrder/NumCrctn with Sfunc? (I am using InterpOrder=2 and no Corrections)
I am trying to figure out what causes this discrepancy, because I would like to keep this controller as is, as it works relatively well on the SImulink side for all the wind speeds, but on the DISCON side of things, it goes unstable for some wind speeds, and especially at 9 m/s close to rated.
There are some differences even at t=0, which I cannot explain entirely, but I have tried to compile DISCON (not all of FAST) in Double Precision, and things improve only slightly. Attached is a file with the first of rows showing DISCON controller output and the second set of row directly from the workspace in Simulink. Is it possible that precision may be causing this divergence in the behavior ? what could I output to assess why the large discontinuity with DISCON?
Thank you for your help!
Rick
I have tried to compile DISCON 4forum.txt (4.33 KB)
Actually, I think I narrowed it down to a different implementation of the filter in my simulink implementation.
I was using the continuous version of the IIR filter, and that worked better at certain wind speeds, as it would keep the controller from going unstable, but not so well at others, where it would yield higher overshoot.
However, I confirmed that if I use single vs double precision I can get the controller to have very different behaviors,
if the controller is not robust enough you may hop over to the unstable side.
I have a related question on Linearization with ServoDyn and fixed-speed/ SIG generator.
I have linearized about an OP in region 3, with all DOFs On (no teeter), ServoDyn ON and VSContrl=0, GenModel=1. (I used the same setting to find the trim pitches originally).
1 .Is that incorrect for a fixed-speed machine? In the old FAST guide the guidance was to set GenDOF to OFF for trim search. I thought I could keep it ON for both Trim Search, (not knowing the torque a-priori without some other calculations) and follow-on linearizations.
From my mbc-averaged matrices, I created a simple SS and open loop model in Simulink. When I linearize in the fashion described above, I would expect that the torque-speed relationship would be somewhat included in the SS system; is that not the case? Of course ED Generator Torque is also an input in this linearized model, so I guess the answer is no, but I am trying to understand it, as SD would have speed as an input and torque as an output, and I could envision a pass-through from SD to ED in this case.
3.The ED outputs from this simple open loop model (passing a 0 delta-torque for the ED Generator Torque input) are fine except for the ServoDyn Outputs (power and torque) that are way off. So I am trying to understand how to handle ServoDyn in the linearization of this fixed-speed machine.
If this post must be placed somewhere else, i will go ahead and do that.
Yes, the slope of the torque-speed curve from SIG should show up as a damping of the generator DOF in the linearized system. The standard linearization input of GenTrq into the ElastoDyn module, represents a perturbation of the generator torque, on top of what is calculated inherently by ServoDyn.
Can you clarify what you mean when you say that the ServoDyn outputs (power and torque) are way off? What are you feeding as input to the linearized model and what are you seeing as output?
I am sending all 0’s for the inputs to debug this system at t=0s. I have got a wind step, but it happens later in the sim.
The ‘OutList’ (matData.DescOuput) contains (among others) 2 ServoDyn channels: SrvD GenPwr, (kW) and SrvD GenTq, (kN-m);
The first output values are for ED HSShftPwr, (kW) is ~69, ED GenSpeed, (rpm) ~1834 (close to what I expect);
but SrvD GenPwr is returned at ~3300 and the torque is 19 (i’d expect ~.36), I am trying to figure out what I am doing wrong.
Are the values you are referring to the operating point (OP) values of these outputs or the perturbed values of the outputs obtained by apply a wind-speed step to the linear model?
Well, I had assumed that every output should be at the OP values when the inputs are set to 0.
I.e., My understanding is that the inputs are deviation with respect to the OP conditions, so for example I would input 0 for the torque (i.e. delta-torque), and same for the wind speed. But I may be totally off of course.
I had not made a linear simulink model before, so I may have other issues, but it is relatively simple, as in “constant source inputs to a state-space block (with matrices from mbc and initial state conditions set to 0 except generator speed) and output dump to workspace”. My intent is to play with the pitch controller at one point, but for now I want to understand how this linearized model works.
The states, inputs and outputs in the linear model all represent perturbations about the OP. So, if you provide zero-valued inputs and time-integrate the linear model, the outputs should also be zero, i.e, this simply means that the OP inputs will result in the OP states and OP outputs. For example, if the wind speed OP is 8 m/s and the power OP is 3300 W, then a 1-m/s wind speed input to the linear model represents a 9-m/s actual wind speed and the power output from the linear model represents the change from 3300 W resulting from stepping from 8 to 9 m/s.
Ah, I guess my nonzero output has to do with how I initialized the states then, which i did not know also represented perturbations, this should fix it for me,
