Hello again... Back to looking at this problem. Have still been unable to get LabVIEW to create a blank data buffer, pass this buffer address to the DLL and then have the DLL return data from the hardware to this buffer address. I have however been able to read data (two chars) at a time from the hardware device until I have read the entire device's memory. This is not the optimal solution and I would prefer if LabVIEW could read the entire buffer in one Call Library Node VI call.
Also buried in the manufacturer's API detail was a brief note that stated the DLL uses the "PASCAL calling convention". This I have been using in the Call Library Node configuration i.e. par4 - using a Pascal String Pointer.... but when I pass an empty buffer the DLL returns with Trawling through the Developer Zone once more yielded this question - "Does Call Library Function convert LV strings to null-terminated before calling the dll?" (search on this for more details). In the LVWUtil32 library (NI FTP site), there is a handy VI called "Generate String Buffer". This generates a blank string buffer which can then be sent to the DLL. Could it be possible that LabVIEW 7.0 is not prepending the length correctly to the blank buffer string when using the Pascal String Pointer? Is there any way to check what the Pascal String Pointer value and contents are when it is executed in the Call Library Node VI? Here's the configuration I'm using for the DLL: void hasp(unsigned long service, unsigned long seed, unsigned long lptnum, unsigned long pass1, unsigned long pass2, unsigned long *Par1, unsigned long *Par2, unsigned long *Par3, PStr Par4); -Chroma
