05-08-2012 06:13 AM
Is there another way to free the (in this case seemingly wrongly still) allocated memory from inside of LV? Or did you have to restart LV all the time?
Regards,
Pedro
05-08-2012 10:27 AM
Pedro,
if messing up the DLL is the reason, you might want to include the DLL as this KB tells.
Norbert
05-09-2012 02:32 AM
Hi Norbert,
already tried that procedre yesterday, had an "unload" within the SubVi, where the DLL is called. so it would be loaded and directly after finishing its job (error in/out as dataflow to make sure it unloads at the right time) it would be unloaded. Did not work out.
Thanks for the input though.
Regards,
Pedro
05-09-2012 03:33 AM - edited 05-09-2012 03:38 AM
Pedro,
this approach only works if ALL CLFN are configured like this. Having at least one "static bound" CLFN in the application will not unload the DLL.....
Norbert
EDIT: My exclamation is true for a single DLL... so having a static bound CLFN to DLL A does not affect other CLFN bound to DLL B....
05-09-2012 03:36 AM
I'll have a look into that later, maybe I did something wrong. Got some other stuff to do right now, but I'll keep you updated. Thanks for the input.
Regards,
Pedro
05-14-2012 07:56 AM
Last Update:
Hi to everyone who invested their time to try and help me,
I have solved the mysterious problem written of in this thread. The wrapper-writer included a logging version in the dll and while looking into this log: LabView memory fragments are transported to my device through the DLL.
The Output Buffer is 64 Bytes long and I always only wrote an array smaller than this, resulting in LabView randomly adding data. Sometimes it worked, sometimes it didn't.
Now I pass over an array the right size, filled with my data and fixed zeros in the rest part of the array and damn yeah, it's working.
Thanks to all of you for your help anyway. Kudos to y'all.
Regards,
Pedro