Control systems

Articles on this page:

• Simple LIDAR example package
• Tip-to-tower clearance as a controller input
• How to exchange data between multiple DLLs coupled to Bladed: User-defined Variables
• How Bladed calculates the optimal mode gain K_opt

Problem

Getting started with LIDAR can seem quite challenging, and some users will find it useful to have a simple template that can be used as a starting point to build a full LIDAR-enabled simulation.

Solution

A simplified template package with all the basic LIDAR functionality is available to download; although this is too simple to be a fully functioning LIDAR controller as-is, it should be fairly easy to build on.

The package includes a v4.16 Bladed project based on demo_a. It uses the demo_a wind file and is intended to link to the LIDAR-enabled external controller provided in this package. You will need to build the controller in Visual Studio(it has been tested with Visual Studo 2022). The file "main.cpp" contains all the LIDAR commands and can be edited by the user to experiment with different functions, outputs etc. / expand the functionality into a full system.

The example provides just one LIDAR output, i.e. the measured wind speed at the LIDAR focal point. It can be viewed in the normal Bladed output screen (or the Results Viewer) in the External Controller output group, as shown:

It also demonstrates how to send some output messages to Bladed, which can be seen in the Calculation Progress screen and the message (.$ME) file as "External Module Note" messages.

Keywords

LIDAR; Controller; Template; Example; Introduction

Problem

Sometimes there is a requirement to have the current nearest tip-to-tower distance as an input to the External Controller DLL. However, it is not available directly as a controller input via the API or swap array.

Solution

This distance is not available as a standard input, but a good approximation of this value can be calculated within an External Loads DLL (supported from Bladed 4.9 onwards) based on other inputs, then passed on to your External Controller DLL code. The recommended method for calculating tip-to-tower distance is summarised in this article. Instead of testing every tower member, we suggest you initially do a visual inspection of the turbine to determine which member is the one that the blade tip passes nearest to. For example, in the 5MW Tripod project:

You can see here that the member to focus on is number 31. Admittedly there are deflections along the member. Therefore the calculated blade tip-to-tower distance will be an approximation, although the error will be quite small.

1. Make sure "Blade motion" at the tip station is enabled in the Specify -- Outputs -- Blade outputs screen (using the "Select Outputs" button), like this:
   
   
   
   
2. Use External Loads API functions GetFlexNodePosition("Tower", Tower_Node_ID), Or GetFlexNodePosition("Blade 1", blade_node_ID), to get the node position in the global frame. (The External Loads DLL user manual and code example can be found in the Bladed installation folder, e.g. C:\DNV\Bladed 4.x\External Loads DLL).
   
   
3. You should then be able to calculate the tip-to-tower separation using the algorithm set out in the article linked above in the External Loads DLL. Set the calculated tip-to-tower as an user variable by API SetNamedUserVariable().
   
   
4. In your External Controller DLL, you can get the tip-to-tower input by API GetNamedUserVariable().
   
   

Keywords

Tip; Tower; Distance; Clearance; Tip-to-tower; Blade-to-tower

Problem

Bladed allows multiple controller DLLs to be linked to Bladed at the same time, as well as the option of an External Loads DLL. Sometimes it is useful / essential for these multiple DLLs to exchange data between them. How can this be achieved?

Solution

User-defined variables are the mechanism we provide for exchanging data (floating point numbers) between multiple external controller DLLs, and between controller and external loads DLLs. This could be useful in a range of cases where you want to write standalone DLLs that can integrate with custom written DLLs through pre-defined interfaces. For instance, if you want to model a LIDAR system and integrate feed-forward control with a control system: in this case, the wind speed read by the LIDAR unit could be processed in one external controller DLL while the control logic is implemented in a separate external controller and data is communicated between the two DLLs. The controller that processed the LIDAR system data could then be a standalone component that integrates with multiple custom written controllers and the communication of data is controlled via named user variables.

Here is more detail regarding how user defined variables can be used in the DLL interfaces we support in Bladed:

Firstly, we offer the function-based external controller API (available from Bladed 4.4 onwards) where the functions are documented in the chm file that is made available to users in the installation directory - e.g. C:\DNV\Bladed 4.18\External Controller. In this controller it is possible for users to set “Named” user variables and get the values of those variables across two different external controllers. It is also possible to use this functionality to share variables and their values between the controller DLL and external loads DLL. There are also functions to get and set indexed user variables in the function based controller interface.

The functions to search for in the documentation are called GetNamedUserVariable() and SetNamedUserVariable(), for both the controller and External Loads DLL interfaces. Help files for the External Loads DLL are found in a folder under the installation root, e.g. C:\DNV\Bladed 4.18\External Loads DLL.

Secondly, Bladed also supports a legacy DISCON (DIScrete CONtroller) controller option. This is still supported as it is widely used in the industry and was the default control option for pre 4.4 versions of Bladed. In this case, an array of elements is passed to the DLL and then set by the user and passed back to Bladed simulation to set pitch and torque demands in response to appropriate measurement signals like generator speed. In this style of controller, the user can set the value of elements 120-129 in the array and these can be accessed by another DISCON style controller. This is analogous to the named user variables in the function based controller. View the documentation here.

If running with a combination of function based and DISCON controller DLLs then it is also possible to set an indexed user variable in a DISCON controller and get this value in the function controller using the get indexed user variable function (and vice versa).

Download an example of how to exchange data between External Loads DLL and External Controller DLL via function-based API. The example External loads DLL script is written with "ExternalLoads_v3" which is available since Bladed 4.13. For Bladed versions before v4.13, the method is the same. Users can refer to Bladed installation folder for different versions of external loads.

Keywords

User defined variables; External controller; External loads; DLL; Data exchange

Problem

How does Bladed calculate the optimal mode gain K_opt?

Why there is a difference between automatically calculated K_opt and the manually calculated K_opt based on the same Performance Coefficients Simulation?

Solution

In Bladed, the nominal rotor diameter (in the "Rotor" Screen) will be used to calculate the optimal mode gain.

After a "performance coefficient" calculation, Cp- λ data can be obtained. An interpolation will be used to find the maximum Cp and the corresponding λ value. These interpolated values are then used by Bladed to find K_opt based on the following equation (from the Theory Manual):

It is this interpolation that is likely the root cause of the discrepancies comparing to the manually calculation. Users can reduce the "Tip Speed Ratio Step" in the performance coefficient calculation parameter settings in order to get a consistent optimal mode gain.

Keywords

Optimal mode gain; Performance coefficient