Mem usage in task manager expands unlimited!

[nistam]

The last few days i created an application that reads data from both serial ports and forwards them to a OPC server. Today i noticed that my application had crashed and Windows had displayed a message that my system was low on virtual memory. I reset the system and i re-run the application, having the task manager opened. I noticed that the memory usage of my exe was taking more and more memory (starting from 21.520KB) as the seconds went by. In 5 minutes my app was using 25Mbytes! What i do in my application exactly, is opening the 2 serial ports then i enter the main while-loop, then every 2 seconds i read from the 2 serials and if i have new data i open a connection to my OPC server (a WinCC scada) and write them to 2 different tags, and finally i close the connection with the OPC. I read two I8 values and i write them to two I8 tags. I must say that i have not used error trapping extensively. Does anybody have come through some such problems with extensive memory usage from one small EXE made with Labview? Could it be possible that my minimal error trapping can cause such problems???

[Louis Manfredi]

I don't see why minimal error trapping should cause the error-- though error trapping might find the error or make it easier for you to find it.

I wonder whether you are creating a new handle, or reference to some resource (the serial port, the OPC server, or something else) each time inside your loop, and failing to destroy that reference when you are done with it. That sort of error can cause a program to gradually soak up all available memory. If so, if you can, better to create only one reference, and use it over and over. Second choice would be to create an new reference every time, but be sure to close the reference when done with it.

Hope this helps, in any case, good luck!

[nistam]

I don't see why minimal error trapping should cause the error--  though error trapping might find the error or make it easier for you to find it.

I wonder whether you are creating a new handle, or reference to some resource (the serial port, the OPC server, or something else) each time inside your loop, and failing to destroy that reference when you are done with it.  That sort of error can cause a program to gradually soak up all available memory.  If so, if you can, better to create only one reference, and use it over and over.  Second choice would be to create an new reference every time, but be sure to close the reference when done with it.

Hope this helps, in any case, good luck!

3925[/snapback]

I open two refferences to both serial ports outside the main loop. I use tunnels when the loop starts. I destroy these refferences after the loop stops. Inside the loop, i open one (or two, it depends on the settings' file) connection to my OPC, ONLY when i have new or changed data. After that i immediately close these refferences. So, nothing remains undestroyed. I'm only thinking of those tunnels for the serial refferences. Maybe i should use shift registers.

[Louis Manfredi]

Hi Nistam:

I agree that you should be O.K. -- assuming that LabView does what it should do in terms of releasing all the memory used by the OPC reference when you close it.

As far as I know, no reason why you should have to use a shift register for the reference to the serial resources-- obviously things can change on the port itself, but as far as I know the reference to it remains unchanged over its lifetime, so there's no need to make it a shift register. Anyone else disagree?

Make sure you haven't inadvertently enabled auto-indexing for the serial port reference (or any thing else) as it tunnels into or out of the loop. (I once had a nasty problem related to an unintended auto-index-- Its amazing how much aggravation a worn out mouse that transmits unintended double-clicks can do. )

At any rate, good luck on the problem.

[proximableu]

Hi!

Maybe this is something with VISA, I think. I have such problem in my application, that must run for a 24 hour without stopping. Serial traffic very extensive, and i used a "daemon" to pick up data from serial port.

I open one reference to port and just only once, flushing buffer do not helps much, there is no difference between sync. and async. Closing daemon, than starting it again , trying to force deallocation, does not help. When I close application (destroying threads - destroying child process) than memory been released.

Maybe it is Win2K issue?

/ProximaBleu

[FLX]

Hi

if it possible for you application leave the OPC-connection open, like the references of the serial communication. Have a look at other references. Sometimes memory is not released, even you close it.

You can use the memory monitoring vi, to figure out which vi is creating the memory leak.

You find it under examples->memmon.llb

Ciao

Alex

[i2dx]

Hi

if it possible for you application leave the OPC-connection open, like the references of the serial communication. Have a look at other references. Sometimes memory is not released, even you close it.

You can use the memory monitoring vi, to figure out which vi is creating the memory leak.

You find it under examples->memmon.llb

Ciao

Alex

4147[/snapback]

in july 2004 i experienced a bug in the LV DataSocket Vis, which showed the same behavior (creating a memory leak) as you described. Furthermore my Programm was crashing when opening more then 7 Items on the OPC-Server simultaneously. I think the new DataSocket VIs in LV 7 / 7.1 are not as well programmed as they should be. The only chance to get rid of this was:

remove all the DS-Vis and attach DS-Connections to Controls which i used as "local Variables", which worked.

This was a very very ugly programming style and i hated this solution, but it was the only way to get the software running "properly". I don't know if NI has fixed this issues in the 7.1.1 Update.

best regards

cb