Zero incorrectly returned from Exported LabVIEW function

[guildfender]

I need to provide a customer with a dll library with function prototypes that exactly match a provided .c header file. I would like to use LabVIEW if at all possible, as fast turnaround on source code modificaiton may be required. LabVIEW cannot export a function with a char* return type (verified by LabVIEW R&D), thus the customer application directly calls a thin wrapper dll (written in CVI) which then calls into the LabVIEW based dll.

I have a subvi that is called by one of the exported VIs. This subvi acquires and analyzes waveform data from an instrument. Memory for a significant waveform (on the order of a MB) is thus dynamically allocated within the subvi. The waveform is not passed up to the caller, and the exported VI returns only a scalar double.

If I remove the subvi from the exported VI's block diagram, other Exported functions behave as expected, However if the offending subVI is added to the block diagram of the exported VI, other exports in the DLL always return a value of "0" (default value for most numeric data types?). This is regardless of whether the Export that includes the SubVI is even called within the client application. It seems that the mere inclusion of the offending SubVI breaks the entire dll.

Both the LabVIEW DLL and the wrapper DLL(which is in CVI) use only the cdecl calling convention.

I get the same behavior for LabVIEW 2011 and 2011 SP1, and for CVI 2009 and 2010. I'm testing using MS Visual Studio C++, since that is the environment for the client application. Behavior is the same in VS 2005 and VS 2010.

I definitely appreciate any insights or ideas regarding how to seek a resolution.

[Aristos Queue]

You say that this subVI acquires data from an instrument. Do the other functions also acquire data from an instrument? Is it possible that this subVI is somehow badly written in that it is locking the instrument so that the others cannot access the data? Is it possibly closing the instrument reference that the others are using? I would check all of the "error out" terminals for all your VIs and see if any of them are returning an error that would be useful... your exported functions probably aren't returning the error to the caller, but on their block diagrams, add a Simple Error Handler.vi that collects all the errors generated on that diagram and see if any of them report when you build the DLL.

You know that removing this subVI makes the rest of the exported functions work correctly. That's an odd workaround to have discovered, which implies to me that something happened that made you test this theory. What did you observe that made you suspect this subVI might be contributing to the problem? Knowing that observation might help the rest of us suggest how this subVI is interacting with the rest of your application.

[candidus]

I had a similar issue. The following worked for me:

Any DLL built by LV exports the a function

long __cdecl LVDLLStatus(char *errStr, int errStrLen, void *module);

I thought that function would tell me what's wrong and called it at the beginning of my C code:

char errStr[128];

LVDLLStatus(errStr, 127, NULL);

It didn't tell me anything but it fixed the issue! I assume that the LV runtime was not fully initialized before this call but that's just a guess.