I have compared with results of FAST exe. and FAST_SFunc. I expected that the results are same, however, are different.
I used 5MW Reference as my model and FAST_SFunc provided by user’s manual, openloop.mdl.
I could get the same simulation results by FAST exe. comparing with Jonkman’s. However, I counldn’t by FAST Simulink.
maybe, should I plus contol logic in provided simulink?
Oh, Please T0T
Dear MinJi Jo,
We’ve had great success comparing the results of the FAST.exe with the results of the open-loop FAST_SFunc; the results are nearly identical in all cases. So, you must have some settings different between your two simulations. I agree with you that it is likely the control settings that are different between the simulations.
Dear Jonkman ^.^
Thanks for your reply!
Although, I can’t be sure of my results. So, I’ll attach my comparing plots of results.
I’ve tried comparing with provided simulation cases by Jonkman.
In case of 1_SteadyWind-8mps,NoControl, I could get the same results between the FAST.exe and the open-loop FAST_SFunc. Here,
However, in other simulation cases, I counldn’t do same plots such as case1.
As you said, must I have some settings for reducing this difference through my control settings?
If so, may I think such as provided FAST Simulink Samples; Test01_SIG?
May I think that control setting is red oval part in below attached picture?
Very very Thanks
Dear MinJi Jo,
Simulation 1 from the recent FAST workshop (materials available from: http://forums.nrel.gov/t/fast/348/1, the NREL 5-MW turbine uses a controller implemented as a DLL (i.e., DISCON.dll) that requires FAST’s interface to GH Bladed-style DLLs, which is not a default option in the current version of FAST. I suspect when you are running Simulation 2 in Simulink, that you are enabling turbine control, but not calling the controller DLL because the default FAST S-Function does not have an interface to the GH Bladed-style DLL. This is the reason for the differences you are seeing between the results obtained from the open-loop FAST simulation in Simulink and the results obtained directly from the FAST executable.
The main reason for running FAST from within Simulink is so that controller logic can be implemented in Simulink.
If I choose the user-defined control options for interfacing with a GH Bladed-style DLL in FAST V7 I have to replace the following files to get the Dll exe:
Do I follow the same procedure if I recompile the FAST_Sfunc using the make_FAST_Sfunc? (Do I replace the UserSubs and UserVSCont_KP and delete the PitchCntrl_ACH and add the BladedDLLInterface?) The reason I am asking is the following: After browsing a few threads in this forum it seems like an Interface between the Sfunc and the GH Bladed DLL style in not possible?
Thank you very much in advance!
It is possible to compile the FAST v7 S Function to call the Bladed DLL, but it is not standard to do so. It is built into the FAST v8 Simulink Interface, but it is a bit more difficult with FAST v7, and I do not currently have time to figure out what those differences are. I do think you should be able to make those same changes to the source code as for the “normal” FAST v7 executable, but there may be some other subtleties in the FAST-Simulink Gateway.
I also know of some people who have compiled the call to the Bladed DLL as a separate S Function and used those values (sometimes modified) as the Simulink inputs to the FAST S Function.
Dear Mr. Jonkman,
Our institute is planning to use the MATLAB/Simulink interface, in order to test a new controller design (basic). My task is to quantify the differences between the FAST.exe and the S-function. Do you maybe have data from your comparison, when you checked the interfaces validity ? You mentioned, that the interfaces results are “nearly identical” and we were just curious, what dimensions and which signals we are talking about and we would be grateful, if you could specify that.
We acknowledge you for your work and your guidance in this forum. Since there will be articles and papers about our work, we just want to be able to quantify our error and the whitewash the weak spots in our simulation.
Again, thank you very much for the possibility to work with this tool.
Assuming you are using FAST v8, then the integration of the structural states in the FAST equations of motion happens identically between the FAST executable and FAST S-Function. Thus, when using an open-loop model with the FAST S-Function, the output should match identically to those of the FAST executable except for differences in compiler settings/optimization e.g. possible differences in the last significant digit. I would suggest that you run the complete CertTest with both the FAST executable and an open-loop model with the FAST S-Function to verify this. We have done this ourselves, but the results where not saved.