LabVIEW
My dll problem
The caller has to provide the memory a function in a DLL is supposed to write into. By not wiring anything to your third parameter you basically do not provide any memory to write to but still tell the function in the last parameter that you passed in a buffer of 180 byte. The function then tries to copy the information it has into this not existing buffer and crashes.
@the phan wrote:I am very new to dll. I try to learn and convert my VIs to LabView dll. Finally, I am successful to generate a Vi that has a call dll library.But it keeps crashing on Labview either by itself or when I close LabView.Attached is a zip file, MLC_sample is main VI, MLC_using dll is the one I would like to use. error.bmp is error message.When I built the dll. At the output string parameter, it always has a "len" parameter adds on.It is the length of string that requires for memory of output string. I have to use some number to get the right data to display.Please tell me what I did wrong when I built my dll.How to make a multi funtions dll library by using LabView VIs.I would like to thank to all of you about "dll" subject and all the sample VIs on the NI forum. I learned alot from it for the last year. Every time I had no solution then it was there.Happy Lunar New Year
What you want to do is using an Initialize Array function. Wire an uInt8 constant to the element input, your 180 constant to the dimenstion size input, then wire the output to a Byte Array To String node and the output from that to the third parameter of your Call Library Node. That is it!
Just a note here: It is not required but common to pass the len parameter that tells the function how long the preallocated space in the output buffer is directly after that output parameter. I would personally move the # of leaves parameter one position earlier so that the output(s) and the accompagning len parameter are at the end of the parameter list.
Now you see why working in LabVIEW is so much easier since you normally don't have to worry about such details. But once you go to DLLs you are basically back in the world of C programming and you have to understand those basic concepts before you can work with it.
To get multiple functions into a DLL you will add several Top Level VIs in the application Builder to your DLL project. Then for each of them you have to define the fucntion prototype, build your DLL and you have several functions in your DLL.\\
Rolf Kalbermatter
Arays of strings will be quite a bitch to deal with both to call that DLL from LabVIEW as well as for the poor guy who is supposed to call your DLL from C or even worse Visual Basic.
@the phan wrote:Hi Rolfk,
I modifed the VI per your advice and it is not crashed any more.
Number of Leaves and MLC data changed so I add to VI some funstions, so "len" can be controlled programable
Thank you for your explaination and suggestion.
Attched is what I modified. Does any output require "len" element?
My next headach is converting some of 200 VIs to DLL.
I used 1D and 2D string arrays to my VIs. Is there any example to use string array as input?
Using 7.1 and XP
But I don't understand what you are trying to do? Creating a DLL someone else should be able to call from non-LabVIEW or just trying to stress test LabVIEW and your nerves by creating a DLL you then try to call from LabVIEW?
If it is the first why do you bother about crating VIs that can call the DLL? And if it is the second, I would recommend you to first take an introduction course into C programming as well as one for more advanced topics.
Rolf Kalbermatter
I have projects with 800 VIs and recompile them each time I change something, so what?
@the phan wrote:Hi Rolf,
I am in second case.
My project is about 200 VIs, some are main and some are sub-VI.
I always built them in one big application.EXE. If I want to modify or fix errors, then I have to rebuild a big.EXE again.
Correct me if I am wrong, I think if I convert some of VIs to DLL and in the future if I want to change them, I just re build that DLLs and keep the application.EXE untouch. It is easier to upgrade.
Going through the DLL interface has among other things the problem of needing to understand some C in order to be able to actually call a DLL of any origin and it also helps to know C if you create a DLL in LabVIEW since you can make the parameter list so that it is more perfomant or easier to call from non-LabVIEW programs. These two things are actually most of the times exclusive meaining you can't do one thing while doing the other too.
Last but not least is your DLL interface limiting your performance consideribly as soon as you get into implementing the functions with one- and twodimensional arrays of strings.
You can with a little work (but a lot less then trying to do this the DLL way) use dynamic VI execution to make certain parts of your VI hierarchy being external to your application. You define certain functionality as external write those VIs seperate, and call them dynamically. There are some examples in LabVIEW and on various sites and this architecture is usually called plugin.
Rolf Kalbermatter
