Debugging the controller


1 Log file

If an error occurs during a simulation with an  External controller (i.e. a controller defined by a dll), it is possible that the issue lies within the dll itself. In that case, you can produce a controller log file with information that will help fix the issue. To do so, you can take the following steps:

  1. When selecting the dll file, tick the Extended debug output box, as shown in the picture below.



  2. Open the %temp% folder. The easiest way to do that is to open an Explorer window, type in %temp% and press Enter, as shown in the picture below



  3. In the %temp% folder, you will find a file named  ashescontrollerdebug-{nnn}.txt, where {nnn} is a unique identifier made of hexadecimal digits and dashes, braces included, as shown in the picture below. Open this file.



Note: there might be several ashescontrollerdebug files in the folder, open the largest one. A new file, with a new identifier, is created each time the controller is started, for instance for each simulation. These files are not deleted by Ashes.


This file contains the values that the swap array has contained at each time step. Tracking down the values of the swap array can help you understand where the error comes from.

Next to it, a file named ashescontroller-rpmvspitch-{nnn}.txt, with the same identifier, gives the time, the rotor speed and the demanded collective pitch angle at each time step, in three tab-separated columns.

Note: these files are written by the controller wrapper, the separate program in which Ashes runs the dll. If the developer-only option Run x64 DLL natively is ticked, the dll runs inside Ashes instead, and the Extended debug output box has no effect.

2 Command window

To check that the dll is working correctly, you can run a quick test in the command window. To do so, you can take the following steps:

  1. Open a command window. You can do so by typing cmd in the Windows Search Bar and opening the Command prompt app, as illustrated in the figure below:



  2. In the command window, go to the folder C:\Program Files\Ashes X.xx\ControllerDllWrapper\x64. You can do so by typing the following command in the command window
    1
    cd C:\Program Files\Ashes X.xx\ControllerDllWrapper\x64

    and pressing enter.

    Note: you have to replace X.xx with your current version of Ashes
     

  3. In the command window, type 
    1
    ControllerDllWrapper.exe --dllpath="YourDllPath"
     and press enter

    For the default NREL 5 MW controller, if you applied the default settings when installing Ashes, the path will be
    1
    "C:\Users\UserName\Documents\Ashes X.xx\DLL Controllers\NREL Offshore 5MW controller\NREL Offshore 5MW controller.dll"


    Note: you have to replace X.xx with your current version of Ashes, and UserName with your Username under Windows


  4. In the command window, type 
    1
    Update
     and press enter. This will perform a simple test on the dll. If the dll is correctly implemented, the text ok will be displayed


3 Files written by the controller

The dll does not run from the folder you selected it in. Ashes keeps its own copy of the dll and of its input files in the project (see Bladed DLL), and during a simulation it writes this copy to a temporary folder in %temp%, named Ashes X.xx-{nnnnnn}. The dll is run from that folder, so any file the controller writes with a relative path ends up there and not next to the original dll. This is the case, for instance, of the debug files (extension .dbg) that ROSCO writes when its logging level is set above 0.

There can be several such folders at once, because Ashes makes a separate copy of the controller for some operations such as running a simulation. Look for the controller output in each of them.

Note: Ashes deletes these folders when it no longer needs them, together with everything the controller wrote in them: for a load case run in a batch, as soon as that simulation has finished, and otherwise when the project is closed or Ashes exits. To keep such files, copy them while the simulation is running, or run the simulation outside a batch and copy them before closing the project. Editing the input files in a temporary folder has no effect on later simulations, since the folder is written again from the copy stored in the project.