LabVIEW
Assign pointer to array in DLL using Call library function
@Sandeepvd wrote:
Please look at ‘DummyWrapper.VI’
There is something wrong with implementing ‘Call Library Function1’
It leads to 2 errors.
I have included VIs which I used to create the DLLs.
Can someone write example code showing correct way to point to an array inside the DLL?
thanks
Sandeep
You can't do that! In C the caller is supposed to allocate array and string buffers. Here the caller is the DummyWrapper VI. So in order to pass an array to the Connect function you have to allocate it in LabVIEW and pass its pointer to the function. You also have to tell the function in the len parameter how large the array is you allocated, this parameter is not meant for you to receive the length of the array from the function.
Basically you have about everything wrong one can do wrong with calling DLLs, so I think you should first read a text book about C programming, especially the chapter about pointers, before we can go on with this.
Besides USing a Call Library Node to call a LabVIEW DLL is a very complicated and uneffective way of doing business. Also I don't think it is a good starting point to learn about the problems and difficulties of C pointers and their handling.
Rolf Kalbermatter
Message Edited by rolfk on 06-22-2005 02:32 AM
@Sandeepvd wrote:
Hello Rolf.
I am pretty sound with pointer concepts however situation is as follows. See what can be done.
I have a set of VIs in LV6.1 from a vendor XYZ to support their device.
VIs do NOT have block diagrams.
The first VI creates an array (unknown size usually up to 10) and gives it to me.
The vendor support is DEAD.
I MUST port VI to 7.0 or to higher version.
To do this, my approach is:
I am creating DLLs of their 6.1 VIs.
Will Call the DLLs from 7.1
I have simulated DLL functionality (which is exactly same as vendor VIs functionality) in DLL VIs I created and have attached.
When I tried to call them thru ‘DummyWrapper.VI’ I hit the problems you saw.
Modifying vendor VIs is out of question.
My question is how can I use them as they are (I realize there will be some memory leakage, but first VI (...Connect.VI) is going to be called only once in several months. I can afford it) ? Can you suggest?
Is there any other way?
Best Regards
Sandeep
You have two options:
1) Configure the array as a pointer to a handle in the DLL build and also call it as such. You won't have any lenght parameter anymore as you get directly the entire array into LabVIEW. This does definitely work if the DLL is the same version as the LabVIEW system it is called from. I'm not quite sure how LabVIEW will deal with it when the DLL is run in a different runtime system than the development system calling it but this probably will create trouble.
2) Or treat the handle as an array pointer. Initialize an array on the LabVIEW diagram level which is large enough for the DLL function to fill in its information, configure this both in the DLL and in the Call Library to be an array passed as C array pointer and in the DLL configure len to be the input AND output length parameter of this array. len will then be passed by reference (as pointer).
Now, wire the intiliaized array to that parameter and the length you have initialized it to, to the len parameter. On return the data will have been copied into the array and len tells you how many elements in the array have been filled in. An Array Resize will crop the array to the real size then.
Option 1) is tricky and almost certainly won't work right when the DLL is compiled in a different version than the LabVIEW system calling it. Option 2) is the best in terms of compatibility and such.
That all said, relying on a driver which is not supported anymore is a very bad decision. What if you run into a bug (Quite likely if they dropped support and if the connector pane of your dummy VIs is an indication of how this driver is written)? All the work already done would be for nothing!
Rolf Kalbermatter
Message Edited by rolfk on 06-23-2005 03:44 AM
@Sandeepvd wrote:
My concerns are as follows:
assumptions:
Array size being passed as an input to any DLL, is bigger than the corresponding data size generated inside the DLL (underlying LV6.1 wrapper code)
There is no inherent memory leakage inside vendor code that is available (which I have no access to but) which has been tested with LV6.1 for 2 years.
#Concern 1
Variable is being passed as an array data pointer. Since it is being passed by reference theoretically as in C, it should not cause any memory leak. However I am unaware about- how LabVIEW understands that the array pointer being passed as an input is for the data it is going to generate? In short I am not clear (but have to be if I want to se this path) how passing by reference works in the (labview) DLL wrapping a labview code.
Basically LabVIEWs Application Builder creates a wrapper C function which does following:
- Build a VI parameter list from the variables on the stack and execute the VI inside the runtime environment using a private VI server method.
- Copy the lesser of the two (lenght of its outcoming array or the number in the incoming len variable) into the array pointer.
- Then if you have configured the len variable to be both an input and output, update the variable in len
with the actually copied number of elements.
- Deallocate its own memory handle completely.
So there is no memory leak to be expected unless the DLL wrapper code has a bug, but as far as I know this worked fine in LabVIEW 6.1. LabVIEW string and array pointers work exactly the same as their C counterparts. The caller has to allocate the space and the callee fills it in by copying its data into it. No memory allocation sharing between caller and callee is done and this is the only way to create libraries, which are compatible with more than one single runtime environment and different versions of LabVIEW really are already two different runtime environments.
Rolf Kalbermatter
Message Edited by rolfk on 06-24-2005 12:51 AM
