LabView 6.0.2 Delphi 5 calling a dll function continuously causes virtual memory error. How can I fix this?

[Patel]

[LabView 6.0.2] I have built a dll that sets the power in dBm to an address 18 for a HP Signal Synthesizer. The address string, and power level get concatenated, then written to the GPIB write function each time the dll is called. The software calling the dll is delphi 5 and does it approximately 40 times a second. This causes a virtual memory error in 20 minutes. How can I fix this problem?

Attached is the following information:
*.pdf file contains software diagram,memory allocation,
and the *.h calling file

[Jeremy Braden]

You should consider upgrading your driver to 488.2 2.10 . Also do you see it leak memory if you run the VI in continious run mode? What happens if you call the dll fewer times a second?

[Patel]

Jeremy,
Thanks for the response.

1) I could upgrade the 488.2 driver, but what does that buy me in terms of the memory leak? How can I upgrade the driver also?

2) I do not see a memory leak when running the VI in continouse mode in LV.
When the delphi code calls the dll only once a minute, it cause a memory handle to increase by 1 also. It seems as though it doesnt matter how many times the dll gets called, the memory leak occurs. Its only a problem when the dll gets called continiously and memeory gets eaten up.


Thanks,
Bhavin

[Jeremy Braden]

If there were problems with the driver, they are likely to have been fixed in the later releases. I just wanted to make sure the problem was not already fixed.

You can upgrade the driver at www.ni.com >> support (in the blue tab) >> drivers and updates (under option 3)

Your information about the memory leak is interesting. What happens if you remove the guts of the VI so that nothing is done? If you still see a leak, double check your delphi code. I do not have delphi, but it would be helpful if you could post your delphi code and the empty dll.

[Patel]

I think you and I are on the same trouble shooting mentality.

I upgraded to NI 488.2 2.10...still have the problem.

Another method:

I fixed the dll so that it does not need to create a string for the input to the GPIB write function. We changed the delphi code to input the address and a string command that sends the exact commands to the signal generator as if we would input a floating integer and have LV produce the string.

This doesn't solve the problem, we still get memory allocation problems.

I am thinking about using NIspy to monitor the GPIB card I/O, but in doing that...I am still monitoring the actual VI and not the dll.

Heres another question:

Is there a way to monitor the dll memory allocation?
Meanin
g, does LV have the function of executing the dll instead fo the VI?

Thanks,
Bhavin