LabVIEW
Do I need Developer studio (C++ programming language) in my computer when I call a dll through my labview?
Solved!
@yemin wrote:
" make sure to configure the additional 4th parameter to be passed by reference (Pointer to Value)."
I didnt understand this. I have 4 parameter one of them is return value, other 3 are inputs. which one is the Additional 4th parameter..Do i need to add one more or change one of those to pointer to value?
Thanks
Well look again at the two function prototypes I pasted. The Call Library Node is setup to return the value as function return value and has three parameters. The C function in the DLL is setup to have no (void) return value and 4 parameters, with the forth being by reference (the & in front of the parameter name, which by the way is C++ only, in C you always have to use the * (star) to signify a pointer, which a reference value is too.
You must make the C function declaration match the function prototype shown in the Call Library Node in the number of parameters and parameter types or you create rubish. Since the C function does not return any value, but your Call Library Node tries to retrieve a value from the A register which is used to return function values, you receive some garbage, which is interpreted as NaN, but really could be anything.
One of the options in the Call Library Node configuration is to specify that a parameter is to be passed by Value (your first three function parameters) or as Pointer (the 4th and last parameter).
That the number of parameters should be correct between caller and callee is however sooooooooooo basic C knowledge, that I would suggest to you to first study a beginners course for C before you dig deeper into using the Call Library Node independant of the C compiler you use.
Congratulations! I guess I should have mentioned this earlier but I forgot that there is a DLL import wizard that will create CLFN VIs from your C++ code automatically.... Maybe. 
Tools > Import > Shared Library (.dll) will open the wizard. You have to identify your C code (and header) files and then it will try to analyze your files and create VIs with icons, error-handling, etc. Note that I said "try"! It's NOT magic but it has worked for me when converting big libraries of C++ functions into LabVIEW VIs which was a BIG time saver. Try it on your DLL and see what you get...
WARNING: If you have the Report Generation Toolkit you must un-install it first or it will cause the DLL wizard to lock up. (unless NI has fixed that bug)
Reading your latest few posts I get a feeling of why? Let me explain to you:
1) Your C code obviously is a self contained executable and was never meant to be called as library, otherwise you would have a proper header file for all the functions that the library exports. So you have to go through your entire code and find all the relevant functions and add the extern "C" and declspec(dllexport) to all functions you want to export from the DLL.
2) Your DLL does also create files, possibly at some fixed location that can't even be changed by the calling application. Personally I would always prefer to create the output files in LabVIEW and simply only do the "complicated" calculations in a DLL.
3) What you have shown so far doesn't look particularly complicated. I really wonder if your time wouldn't have been better spent learning to understand what the C code does and then porting it all to LabVIEW. One important question in this respect is how many SLOCs (source line of codes) are we talking about in this C code? Unless it is already a well designed library you won't get away without studying the code anyhow in depth to be able to export the right functions and interface them to LabVIEW, but then you have already done most of the hard work to reimplement them in LabVIEW. If we talk about many tenthousends of SLOCs then maybe going through all the DLL import pericles could be a faster way of solving this problem, but if it is a moderately sized C code, converting everthing to LabVIEW is likely faster and much easier to debug when you integrate it into an application. Debugging a DLL directly from within LabVIEW is always an additional hassle and your use of C Builder is likely another obstacle in doing source code debugging in DLL code called from LabVIEW.
4) The error you get after calling your function most likely is caused by some illegal action in your C code. What it is? Well without looking at the source code I could just as much guess it has to do with the position of the moon when you call that code. But then I don't really feel like reviewing some less than impressive code either! The error might always have existed but if it was just a single start up once executable, shoot once and then die anyhow after creating the result file, it may never have surfaced to the Windows user. Or it could be something you did to make the code callable from LabVIEW, such as exporting the functions you thought you needed in LabVIEW but not initializing memory buffers used in those functions and originally initialized in the main function of your original program.
In short I do really wonder hard if you would not already have a fully working solution if you simply had ported everything to LabVIEW and forget about creating a DLL and trying to import it into LabVIEW.
Well all I can say to this is: The powers in your case are making things triple complicated and should be replaced.
As to your problem: Oh well, those JPG images show absolutely nothing relevant so no joy there.
