I am trying to implement a yaw control algorithm using the bladded dll method. For this reason I have set a simple simulation of 100s with yaw rate at 1deg/s = 0.01745rad/s. The YCMode is set to 5 and the YawDof is set to True. From the bladed user manual, set the desired yaw rate at the variable avrSWAP(48) and the variable avrSWAP(29 ) = 0 as a yaw rate control is intended to be implemented.
The simulation unfortunately crashed in the first 10 seconds with the following message
I was expecting this error, but not that soon. After plotting the results, the yaw speed was not the one that I am demanding from my dll
Then setting the yaw rate to zero, I am expecting no movements but instead it appears that the yaw position varies with the yaw error.
I then thought that there is no damping so I set the avrSWAP(102) = 2 and avrSWAP(104) = 1.916E+07, but no improvement was realised. After checking the servodyn code I have realised that these values are not in use. Finally, I tried the same with the Yaw brake torque demand avrSWAP(108), and once again no improvement was realised
Is there anything I am missing from the configuration? Thank you in advance, I hope to hear from you.
Have you set TYCOn = 0 s and appropriate values of YawSpr and YawDamp in the ServoDyn input file? These are needed to use active yaw control from Bladed-style DLLs.
You can avoid receiving errors about “no valid value of phi” by upgrading AeroDyn v15, as reported in the following forum topic: http://forums.nrel.gov/t/fast-v8-aerodyn-v15-convergence-problems-for-low-speed-high-turbulence/1532/2.
As you noticed in the source code, avrSWAP(102), avrSWAP(104), avrSWAP(108) etc. are currently ignored by ServoDyn.
Thank you for your quick response.
with regards to servodyn, I have the following configuration:
Should i change the variables YawSpr and YawDamp such as that the results would be the expected ones?
With regards to the rest of the variables: TYawManS, YawManRat,NacYawF are they in use when the dll is used? I thought they weren’t.
Using the aforementioned yaw control configuration, I demand from my dll 0deg/s yaw rate and the results are as follows:
significant yawing is taking place where it shouldn’t. Please let me know if there are any other things I that I should check?
Thank you in advance once again!
The values you’ve used for YawSpr and YawDamp are those from the NREL 5-MW turbine. Is this the turbine you are simulating? If not, are these values still appropriate for your turbine?
Yes, the override yaw maneuvers are still used when the Bladed-style DLL control is enabled. In this case, the yaw maneuver will override the DLL e.g. useful for forcing faults in the controller. However, in you example, you’ve disabled the yaw maneuver by setting TYawManS > TMax.
If your YawSpr and YawDamp are set appriopriately, I’m not sure why your yaw is not responding as it should. Can you run a test whereby you force a yaw maneuver with TYawManS, YawManRat, and NacYawF to see if the yaw responds as you’d expect?
Indeed the turbine I am simulating is the NREL-5MW, sorry didn’t mentioned it earlier.
I did run a test as you described and it worked well. Based on the bladed user manual, the dll output avrSWAP(48) is supposed to export yaw rate. Is it still the case or I should demand yaw angles? I would like to have the yaw control to be activated based on the conditions and with various yaw rates, This is why I have chosen yaw rate control option. In the case where yaw angles are demanded, things can get complicated. I am sure there is something I am missing, but I don’t know what is it.
Thanks for your quick and kind responds
Because the yaw override maneuver functions properly, I would guess the problem is coming from the DLL. Yes, the avrSWAP(48) is supposed to export the yaw rate (not the angle). Have you verified that the DLL is properly exporting the yaw rate?
Thank you again for your quick reply.
I have verified the yaw rate demand by exporting the .dbg file from the dll. Indeed it sends out what I am requesting. I have hard-coded the yaw rate in order to eliminate errors. However, The turbine seems to be yawing.
Thanks again and kind regards
I looked at the FAST v8 source code and found the problem. In routine CalculateStandardYaw of ServoDyn.f90, the yaw angle (position) command when the yaw rate is commanded from a Bladed-style DLL is calculated by adding an increment of YawRateCom*DT to the current yaw angle. However, the yaw angle command should be defined as the integral of the yaw rate command, regardless of the current yaw angle (i.e. the yaw angle command must become a state of ServoDyn). As it is currently implemented (incorrectly), when the yaw rate commanded from a Bladed-style DLL is zero, the yaw angle is commanded to be current yaw angle, effectively eliminating the yaw spring stiffness, yielding large yaw errors. I’ll flag this as a bug in ServoDyn. I would not use yaw control from Bladed-style DLL controllers until this bug is fixed.
Thank you very much for your response and your explanation. I’ll keep an eye on the next Fast release.
Hello Jason, Panagiotis,
Has either of you found a solution to this problem? We are running into the exact same problem with our .DLL controller.
Bart Doekemeijer, TU Delft
Unfortunately, NREL has not yet had the time to fix this bug. It’s still on our to-do list.