Problems with avcMsg

[Anish.John.Paul]

Hello,

I am trying to replicate the NREL 5MW controller example. I am generating a Bladed style DLL with C++.

When I send a message to the screen using avcMsg I get a lot of binary characters(?) and some bits of the ServoDyn solve options, but no message. (I can set *aviFail=0 to suppress the output to screen, but I’d like to see some messages during the simulation).
Screenshot attached.

The problem is quite similar to what has been discussed in this thread:

Recompiling BLADED .dll for 64-bit

Hi, Aisha. Theoretically, there is no difference in how the Bladed DLL is called between FAST v7 and v6. You may see some differences with messages returned from the DLL because FAST v8 is a little more rigorous in dealing with null characters that are at the end of C strings, but if you’ve written the DLL in Fortran, you shouldn’t see any difference in FAST v8. The name “DISCON.IN” was hard-coded in FAST v7; in FAST v8 you specify that name in the ServoDyn input file. What the DLL does with th…

I have followed the advice in that thread, but I still can’t figure out what the issue is.

I can use avcOutname and write out the error messages to a log file, so I’m positive the DLL isn’t mangling the message.

I’m using OpenFAST v1.0.0, but have the same issue with v2.3.0.

Any help would be appreciated… Thanks!

[Andy.Platt]

Does any of your intended message appear, or is it all junk?

This appears like some argument isn’t aligning at the interface. The content of the error message looks a bit like it might a garbled form of the avcOUTNAME argument. Can you share the interface info from the procedure in the DLL?

Alternatively, it might be that the avcMSG from the DLL is not terminated correctly. OpenFAST is expecting a C_NULL_CHAR to indicate the end of the message – everything after it is ignored. However, this doesn’t seem like a likely explanation though.

• Andy

[Anish.John.Paul]

Hi Andy,

None of my intended messages appear. Its all junk.

My interface info:

extern “C” {
void __declspec(dllexport) __cdecl DISCON(float* avrSwap,int* aviFail, char* accInfile, char* avcOutname, char* avcMsg);}

// Main DLL routine
void __declspec(dllexport) __cdecl DISCON(float* avrSwap,int* aviFail, char* accInfile, char* avcOutname, char* avcMsg)
{
…
}

Regarding the null-termination of the array, I’ve tried the built-in functions in C++ [c_str()] as well as the c-style char arrays to create *acvMsg, but the garbled message still persists.

[Anish.John.Paul]

Hi again Andy,

I seem to have fixed the issue. It had nothing to do with OpenFAST, so apologies for that.

What I was doing was converting my c++ string to a char array and then assigning the result to avcMsg. (I’m still not sure why this doesn’t work). The gibberish that results is apparently due to a dangling pointer. (Again, not sure why this happens.)

I replaced the pointer assignment operation with memcpy and it all works fine now.

Thanks again for your time.

-Anish

[Andy.Platt]

Hi Anish,

Glad you found the source of the issue.

Thanks for letting us know what the root cause. It’s good to know that a dangling pointer could cause this issue.

Cheers,
Andy