Question: Recommended path to replace Bladed-style DLL control with an external PLC controller in OpenFAST

[zzybrilliant]

Hello OpenFAST developers,

I am working on a PLC–OpenFAST co-simulation / HIL-style setup and would like to ask for guidance on the recommended path for controller handover from the current Bladed-style DLL controller to an external PLC controller.

Current setup

• OpenFAST version: v3.5.4
• Platform: Linux
• Current controller interface: ServoDyn with Bladed-style DLL
• ServoDyn key settings:
  • PCMode = 5
  • VSContrl = 5
  • YCMode = 5
  • DLL_FileName = "./libdiscon.so"
  • DLL_InFile = "DISCON.IN"
  • DLL_DT = 0.025

The current OpenFAST model runs successfully with the existing libdiscon.so controller.

What I have already done

I have built a PLC + Python + ADS communication loop outside OpenFAST:

• Python reads OpenFAST output signals (GenSpeed, PitchMeas, YawPos, etc.)
• Python sends these signals to a Beckhoff PLC via ADS
• The PLC computes control outputs:
  • generator torque command
  • collective pitch command
  • yaw rate command

At this stage, this works as an “output replay / controller development” setup, but the PLC commands are not yet fed back into OpenFAST.

What I want to achieve

My goal is to gradually replace the current DLL-based controller and let the PLC become the actual external controller for OpenFAST, ideally in this order:

1. first generator torque
2. then pitch
3. then yaw

What I tried

I tried modifying ServoDyn control modes to remove DLL torque control:

• VSContrl = 0
• and also VSContrl = 1

However, I ran into problems:

1. With VSContrl = 0, the generator model path requires valid generator parameters that are not currently available in my case.
2. With VSContrl = 1, OpenFAST fails during initialization with:
   u%HSS_Spd is negative. Simple variable-speed control model is not valid for motoring situations.

So at the moment, directly switching away from the DLL torque control path does not seem to be a practical route for this model.

My questions

1. For an existing model that already runs with PCMode=5 / VSContrl=5 / YCMode=5, what is the recommended way to replace the controller with an external PLC controller?
2. Is the preferred approach to:
   • modify / replace the existing Bladed-style DLL (libdiscon.so), or
   • use another OpenFAST external control interface?
3. If I only want to hand over generator torque control first while keeping pitch and yaw under the current DLL, is that a reasonable incremental path?
4. Are there recommended examples or repositories showing how to build a custom Bladed-style DLL / SO that exchanges signals with an external process (e.g. socket/shared memory/IPC) rather than implementing the controller internally?
5. Is there any better-supported path in OpenFAST for real-time / co-simulation style external control handover?

Additional note

I do have access to:

• DISCON.IN
• libdiscon.so
• and the existing ServoDyn file

But I do not currently have the source code used to build libdiscon.so, so I am trying to understand whether I should:

• look for/build a replacement custom DLL/SO, or
• use another external control mechanism supported by OpenFAST.

Any advice on the recommended architecture or workflow would be greatly appreciated.

Thank you.

[jjonkman]

Dear @zzybrilliant,

I have not personally done what you are proposing, so, I can't offer detailed guidance. But it sounds like you have a way to transfer signals from OpenFAST to your PLC and are seeking a way to send signals from your PLC to OpenFAST; is that correct? You haven't said how you are sending signals from OpenFAST to your PLC, but can the approach you are using be adapted to send signals the other way?

My guess is some customization of the OpenFAST source code will be required regardless. I could foresee you adopting PCMode, VSContrl, and/or YCMode options 3 (user-defined routine), 4 (user-defined from Simulink), or 5 (user-defined from DLL) and which is better probably depends on your details. With (3) and (5), your controller could send and receive signals to/from OpenFAST by customizing the routines (either separate user-defined routines for pitch, torque, and yaw for (3) or by customizating the DLL controller interface for all signals combined in (5)), and OpenFAST would act as the driver and the routines would wait until a signal is received before OpenFAST continues. With (4), your external controller would send and receive signals to/from OpenFAST, but call OpenFAST in the process.

Whether it is OK to partially replace output signals from an DLL controller depends on the controller you are using. Often with DISCON controller, the pitch, torque, and yaw logic is coupled, so, using some outputs while ignoring others may cause unexpected behavior.

Best regards,