ServoDyn - Measured Electrical Power signal not being sent to Bladed-style DLL

Wind & Water Computer-Aided Engineering Software Tools
1

I’m using Servodyn within FAST version 8.16. I am using a controller dll through the Bladed interface which has a supervisory trip which uses the “Measured Electrical Power” signal (Record 15). This controller records the measured electrical power as zero even when the output electrical power from FAST is non-zero. I have used the controller dll with Bladed and the behaviour is not the same. I’ve had a look at the source for ServoDyn but can’t seem to find out exactly why the value is not updated. Perhaps something to do with checking if the generator is on?

     CASE ( ControlMode_DLL )                                ! User-defined variable-speed control from Bladed-style DLL
        
        ! bjj: I believe this is how the old logic worked, but perhaps now we can be more clever about checking if the generator is off
        
        IF ( m%dll_data%GenState /= 0_IntKi ) THEN ! generator is on    
           
           GenTrq = m%dll_data%GenTrq
           ElecPwr = CalculateElecPwr( GenTrq, u, p )
2

Dear James,

I wouldn’t expect this, but are you saying that the GenPwr output of ServoDyn is different than avrSWAP(15) (and not just delayed by 1 time step)?

Is the controller DLL you are using setting the GenState (avrSWAP(35) to 0?

Best regards,

3

Dear Jason,

I have the same problem, but the value isn’t zero. I see that the value of the measured electrical power is the inital value from 0 s during the whole simulation. GenState is set to 1.

Thank you.

Best regards,
René

Edit: The measured generator torque (GenTrq_prev) shows the same behaviour.

4

Dear René,

Bonnie Jonkman of Envision Energy recently reported to me that she found a minor bug in the FAST driver/glue code that resulted in incorrect values of the generator torque and electrical power being sent from ServoDyn to Bladed-style DLLs. While she is implementing a more thorough clean-up, she told me that a simple fix is to change one line in FAST_Solver.f90/SolveOption2 i.e. change the line:

to

and recompile FAST. Does that resolve your problem?

We’ll get this fixed in a future release of FAST.

Best regards,

5

Dear Jason,

Thank you for your answer. I will try this tomorrow.

Thank you very much for your always fast and helpful answers.

Best regards,
René

6

Dear Jason,

In FAST v8.16.00a-bjj this line is a little bit different:

CALL SrvD_InputSolve( p_FAST, m_FAST, SrvD%Input(1), ED%Output(1), IfW%y, OpFM%y, BD%y, MeshMapData, ErrStat2, ErrMsg2, SrvD%y_prev   )

So, there isn’t “SC%y” in this line.

BUt it works with changing only “SrvD%y_prev” to “SrvD%y”.

Thank you very much.

Best regards,
René

7

Dear René,

OK, great! (The SC%y was added recently to support a wind-farm-wide supercontroller (still to be publicly released).)

Best regards,