Trying to get dll calls to work like c++

[PrinceOfFiziks]

Hi,

I understand there have been many posts about dll files.  I have reviewed them and found nothing that helps me.  I have a segment of c++ code that communicates with a digital correlator, reading data from it.  The c++ code works fine, but when I wrote the code in Labview, I get results that are reasonable sometimes....sometimes I get good data, sometimes odd data, and sometimes no data.  The c++ code ALWAYS yields good data.  The function prototypes in each of the call library functions matches that in the c++ code. 

The C++ code is attached.

NOTE THAT there are a few things (like calculating delay times and writing to file I don't do in the labview code).

The labview code never outputs any values in TraceA or TraceB, which should be values around 300,000.  The DLL location is set correctly, as evidenced by the fact that the code works....just not consistently.

Any help would be greatly appreciated.

Josh

[smercurio_fc]

I'm a little confused about what works, and what doesn't. You said the LabVIEW code sometimes gets good data, but then you later said that the LabVIEW code never output any values in TraceA or TraceB. So, what is this good data that you're getting? I am assuming that none of the CLFN calls generate errors?

Tips:

• Instead of using all of those "Reinitialize to Default" calls, just set the "Clear indicators when called" option in the VI Properties >> Execution.
• Using a stacked sequence frame like that is ugly. Use dataflow or a state machine construction. Dataflow will allow you to daisy-chain the calls. A state machine will allow you to break out on error.

[PrinceOfFiziks]

The most important output to me is the correlation data array, called correlation function in labview, and called corr in the c++ code.  The USBUpdate function is the main data acquisition step.....it provides 5 items (ElapsedTime, tracecnt, corr, traceA, traceB).  All yield sensible results when the C++ code is executed.  In Labview, traceA and traceB ALWAYS yield arrays of all 0s, which is a problem, since values should be around 300,000.  The Correlation function (corr) is the most important data to me....from Labview, it is sometimes sensible, sometimes not (it works correctly about 15% of runs)....from C++ it always yields sensible data.

Josh

[nathand]

I don't have LabVIEW 2010 installed yet so I can't open your VI, but I'd be happy to take a look if you save it back to 2009.  It sounds like there may be a problem with the way you're allocating memory for the DLL to use (or perhaps you are not allocating enough memory).  Try setting the error checking to Maximum in the Call Library Node setup and see if your code generates any errors.

[frankcase]

Hi,

Did you ever get this to work. If so, i would like to get a working copy of your file as it would really help me out.

Best,

Frank

[rolfk]

Your message is very clear!

I have no idea how the fact that this particular code was made to work would help you unless you try to use the same DLL which would seem rather strange. As to what the OP posters problem was:

One has to provide buffers to DLL functions for ALL parameters when one calls them. Yes LabVIEW does take care about buffer allocations everywhere else so you don't have to worry about that, but when calling C code, LabVIEW can't even guess what buffers the function may need. And therefore it correctly doesn't try to guess at all.

Those arrays that the function should write into, have to be allocated BEFORE one calls the function. It's the single most problem why DLL calls don't work as expected either returning rubbish or crashing. And anyone claiming to have read all the posts about DLL calling on this board or also on lavag.org should have gotten across at least two dozen messages from me where I pointed that out and explained it in detail.

in detail: The graph arrays do get initialized but in the same frame all control get initialized to default. That is completely wrong! one does either one or the other but not both and definitly not in the same frame because of uncertainety which is executed first.

nTrace is initialized to 0 and then used as indication in the CallLibrary Node, how large the array needs to be. Well a 0 element array is just that an array of no content, therefore a buffer that can hold no information and therefore it's sheer unluck that the Call Library Node doesn't crash.