02-03-2014
03:39 AM
- last edited on
06-09-2025
06:28 PM
by
Content Cleaner
Hello,
Been searching and spent a couple of days on this....
I have the following function in C++, which returns a pointer(float *) to a float array, which I need to be dumped into a code block. I created the DLL and I loaded it into the DLL-to-LV function(everything is ifne I can see it and I add the parameters), and set it up accordingly following examples. I then had to figure out how to get the pointer to work. All examples are using U32's, not a float...there is no float * return type...or double....how is that handled?
So I think I'm sort of on the right track by searching, and using the example here:
http://www.ni.com/example/28672/en/
I am pretty sure it is wrong b/c I simulate the DLL code in MSVS and it works perfectly, but when I port it over, the data is wrong...but I do get size of 4 floats. ALSO...the DLL memory doesnt reset...so if I run it for the first time, it will calculate data for n=0 ==> n = 1000(see attached pic), but the next run instead of repeat when I press play, the data will start off at n=1000, ==> n = 2000 All I want to do is pass an array of size 3 data type float our of my DLL, and into labview...and after the LV run and stops, the memory will NOT keep it's value but reinitialize...
Here is the Function, call others but you can see it:
float * getYawPitchRoll(float Gx, float Gy, float Gz, float Ax, float Ay, float Az, __int32 msTimeStamp)
{
float * YPRptr = YPRDEG; // DATA ARRAY SIZE OF 3 FLOATS
getYawPitchRollRad(Gx, Gy, Gz, Ax, Ay, Az, msTimeStamp); // writes to a global variable array(float) 'YPRDEG'
UpdateYPRDEG();
return YPRptr;
}
**** Also attached picture of LV code and Library setup *****
Why is this so rediculous for LV to handle?
Please help, I am out of gas here...
Thanks,
-Peter
Solved! Go to Solution.
02-03-2014 10:20 AM
Instead of returning a pointer to your array of results, pass a pointer to an array into your dll and put the results in that.
There's an example of this included with LabVIEW, which can be found at <LabVIEW Install directory>\examples\Connectivity\Libraries and Executables\DLL Calling VIs\ARRAYfloor1D.vi (Location correct for LV2013)
The example uses an I32, which will of course need to be changed to a float for your use.
MC
02-03-2014 11:46 AM
MC....great idea..thanks for the help dood, I'll bust this and reply back,
-Peter
02-03-2014 12:25 PM
Hey MC or Others,
Do you have any idea of the memory issue?
basically my DLL is a series of functions that call eachother, with a single top function. In this DLL I have say a dozen global variable, which are used by the function for calculations in my function set.
When I run it on the first time, the calculation calculate like the variables are init'ed, but when I run it for the 2nd time, the DLL global variables are holding their value in memory.
Any ideas?
Thanks,
-Peter
02-03-2014 12:36 PM
You need to unload your DLL by passing a null into the CFN.
For some reason, link posting isn't working for me right now.
Just search for Unload DLL in the forums and you should get some good discussions on the topic.
02-03-2014 01:03 PM
Hey Taki,
Great thanks I'll lok this up, but I also cannot connect this float array into my function via my float * ptr parameter....
See attached picture guys...
02-03-2014 01:24 PM
02-03-2014 03:19 PM
Guys (& Girls),
Thanks for al of the help...I was able to fix the memory issue by creating a Initialization function in the DLL which resets the globals...then I exported it on the DLL, making it available to LV(DLL export)...then I used the callback, reserve option to cal the initialization function. I looked up this callback thing (I am a HW guy), and it looks like these are function that are caled by the VI upon start of VI and exit of VI, so I just reset it...
When I loop the DLL, it saves the value and when I hot the stop button, it will reset the globals upon restart of the VI.
Hopefully this technique is a good design practice, if not let me know, but it makes sense.
*** See attached picture to help others with my plight ****
Thanks for all of the help,
-Peter