FAST or OpenFAST for LabView / "Call Library Function" block

[hbasbas]

Dear all,

Bug description
I would like to run floating offshore model on LabView development in real time (RT) environment. As Dr. Jonkman told me, there is no update since FASTv7 for the Labview environment, we only have the fortran code "FAST_RT_DLL.f90" (or OPENFAST_RT_DLL.f90 for OpenFAST version). So I moved to FASTv7 and I tried to run the LabView demo program. However, LabView crashes ... For sure, it comes from the "Call Library Function" who calls the compiled (by FAST developers) DLL file with "Compile_FASTforLabview.bat".

So here my questions :

(1) Is the demo able to run without any changes ? Or should I modify the "Compile_FASTforLabview.bat" to create a new DLL file ?

(2) If we need to compile again the DLL file, should I specify the location of the IVF compiler ? Is it obligatory to have the version "10.1.024\IA32\Bin\IFORTVARS.bat" ?

(3) As explained in "UsingFAST4Labview" pdf file, we should use the Labview 2012 version. Could we use a newer version ? And if we don't use the PXI target, can we run the LabView program only to visualize the output on "waveform chart" labview block ? If yes, there is no need of LabView RT 2012 right ?

(4) If I succeed all the different steps for Fastv7, is there some changes to do for OpenFAST ? Because the OPENFAST_RT_DLL.f90 file seems to be the same as Fast version 7.

I could not find any answer on this in NREL forum or in the github issues. I have already contacted P. Fleming who is the developer of the Labview demo program but he suggested me to ask my questions here.

Best regards,

Hedi BASBAS

[hbasbas]

@bjonkman maybe you can help me ...

[bjonkman]

@hbasbas,

It has been a long time since I've looked at this, so I will just tell you what I remember.

When we made the LabView interface with FAST7, we had to deal with some incompatibilities between the Intel Fortran and Visual Studio assumptions about what Windows API routines are available and what LabView's "Windows-like environment" had available. We used that specific compiler and version of Visual Studio because it had the fewest conflicts, though LabView still needed to be modified to contain maybe 5 or 10 additional Windows API routines. Those new API routines were included in Labview version 2012.

I know that we were able to successfully run the interface for the specific versions that are listed in that "UsingFAST4Labview" pdf file included in the last FAST 7 release. It is possible that a newer compiler could work, but I'd be surprised. Newer compilers tend to take advantage of more/different parts of the Windows API. I would guess that using a newer version of LabView would be more likely to succeed. I have never used Labview personally, though, so I can't comment on any of the details you ask about.

We never updated the Labview interface for OpenFAST. It likely would require quite a bit of work for the new OpenFAST framework (though it is probably similar to the changes that were made for the Simulink interface). Some of the newer changes to OpenFAST may also not build on such an old compiler, too. I know there are some Fortran 2008 features in the current code base, but it may be fairly straightforward to replace them with something that builds on an older compiler.

[hbasbas]

@bjonkman

Thank you for your reply. So it seems more difficult than I thought.

Maybe, it can help someone : I re-compiled FAST4Labview with Visual Studio 2019 and Intel Visual Fortran Compiler in 32 bits (for Labview 2012 32 bits) from Intel Parralel Studio XE 2020 Update 4 (check that a gcc 32 bit is well installed before). It compiles well ! However, when I move to Labview, I had to change the location of the input file (.fst) and other primary files (.dat). All the "call DLL library" works but the subVI "simple control" didn't run without error. If deleted, the simulation with Labview is completed.

[hbasbas]

@bjonkman

Since I completed the compilation of FASTv7 to obtain a .dll file for LabView. I am trying to do the same for OpenFAST with the VisualStudio project given in the github.

(1) I remove the FAST_Prog.f90 from FAST project and I replace it by OPEN_FAST_DLL.f90

(2) Are the (FAST_Registry, FASTlib, MAP_dll and OpenFAST-Simulink) projects necessary for dll compilation in the case of Labview ? I don't understand the use of these projects ...

(3) How could I modify the properties to obtain an output solution as .dll instead of .exe ?

(4) II think the best solution would be to create a new VS project. But should I compile all the module of openFAST or I can select only some of them. For example, FASTv7 with the batch file "CompileFast4Labview", it only select some module (aerodyn, inflow, NWTC and FASTlib).

Best regards,

[bjonkman]

First of all, I expect that you will be able to successfully compile and build the DLL with a lot of different compilers. The problem is in successfully running the DLL that you build. If you examine the DLL you created with something like Dependency Walker (or dumpbin), you can see what the DLL depends on. I think Paul Flemming used some program from LabView to examine the DLL before running it to determine if it would work with LabView when we first released the LabView interface for FAST7.

As an example, I've opened the OpenFAST-Simulink DLL for use with the Simulink interface using Dependency Walker here:

You can see it primarily depends on 4 DLLs:

• MAP_x64 for the MAP++ module
• kernel32 (Windows API)
• imagehlp (system routines for debugging)
• libmex (for printing to Matlab's command prompt)

In the LabView build, you won't have the libmex DLL, and we delay-load the imagehlp DLL so that it is called only if there is a catastrophic error--in which case it will just crash LabView instead of generating an error message. So, you'd still have the MAP++ DLL and the kernel32 DLL. If you look inside the kernel32 DLL at which functions it needs, you will see a long list. All of those functions have to be implemented in the LabView version if you want the DLL to run in LabView. As I said before, there were many fewer functions required when it was built with older versions of the compiler/linker. I would guess that the simple control was calling something that required one of those missing functions.

1. You will have to re-write Open_FAST_DLL.f90 because OpenFAST has a completely different data flow and data structures than FAST7.

2. Yes, some of them are.

   • The FAST_Registry generates *_Types.f90 files that are required to build the solution. You could remove it if you don't plan on changing any of the data types in any of the OpenFAST source code.
   • OpenFAST-Simulink builds the DLL for the Simulink interface. You won't need it, but you might want to start with this for the DLL to use with LabView: it's closer to what you'll want than the FAST_Prog project.
   • FASTlib contains most of the computational code for OpenFAST, and MAP_dll contains the code for MAP++. You will need both of them. You will have to make sure all of the compiling and linking commands between those projects are consistent.

I would suggest you start by looking at how the data structures are implemented in OpenFAST and find out how the current LabView DLL communicates with LabView (what subroutine calls are there? what data does LabView send to FAST? what data does FAST send to LabView?).

Then look at how the Simulink interface works: generally, there is an initialization call, a time-step update call, and an end call. That Simulink interface will help you figure out some of the controls data that is passed between DLLs, which should apply to the LabView interface as well. Then you will have to modify it specifically to get it in the form that LabView needs. You may also have to add an end call in the LabView DLL.

After that, you will likely have to delve into a lot of compiling options to get it running in the LabView environment.

This is not going to be a quick task, and I don't have time to walk through all of the steps that it will take to get this to work.

[hbasbas]

Thank you for your very detailed reply. It helps me a lot. I will try to follow the described steps and if necessary, I will come back to this issues to get some help and/or present some solutions.