Pb to Stop my application after long time of use!

[Dominique BOISSET]

Hello,
I use LABVIEW 5.01 and I have a problem with the application I made.
This application use a lot of sub VI (Logical I/O, RS232, sequential...).
When this application is running during many hours (More than 1 Day),
it's very long to quit the appication. A white screen appears and the CPU
time
is used at 100% during 2 or 3 minutes.
This problem does not appear if the application is run during a short time.

Did somebody already have this problem?
How to resolve it?

D.BOISSET

[Greg_McKaskle2]

> I use LABVIEW 5.01 and I have a problem with the application I made.
> This application use a lot of sub VI (Logical I/O, RS232, sequential...).
> When this application is running during many hours (More than 1 Day),
> it's very long to quit the appication. A white screen appears and the CPU
> time
> is used at 100% during 2 or 3 minutes.
> This problem does not appear if the application is run during a short time.
>
> Did somebody already have this problem?
> How to resolve it?

Have you looked at the memory usage of your application? One thing that can
cause this is that your app is making lots of strings or arrays and storing
them into shift registers or globals. When LV quits, it will release them
back to the OS. If you open the Task Manager or a similar vie
wing utility,
you can monitor the memory usage.

Another possibility is that there are lots of open I/O sessions that are not
being closed. Again, on exit, LV will release them back to the OS. These
are a bit harder to find/detect, but they can either be closed when you are
finished with them, or you can open them outside the loop so that fewer of
them are allocated.

Greg McKaskle

[CraigGraham]

> Another possibility is that there are lots of open I/O sessions that are
not
> being closed. Again, on exit, LV will release them back to the OS. These
> are a bit harder to find/detect, but they can either be closed when you
are
> finished with them, or you can open them outside the loop so that fewer of
> them are allocated.

Another possibility, if it's Win95/98, is that the memory pool is becoming
fragmented by frequent allocation/deallocation of large arrays, causing a
gradual degradation in machine performance over time. If you use large
arrays in there, it may be better to allocate them beforehand and use
"replace array element" rather than allocating on the fly by using "build
array" or having arrays built at the output of a loop.

[AndersB]

Craig Graham wrote in message
news:8d4es9$cr6$1@sponge.lancs.ac.uk...
>
> > Another possibility is that there are lots of open I/O sessions that are
> not
> > being closed. Again, on exit, LV will release them back to the OS.
These
> > are a bit harder to find/detect, but they can either be closed when you
> are
> > finished with them, or you can open them outside the loop so that fewer
of
> > them are allocated.
>
> Another possibility, if it's Win95/98, is that the memory pool is becoming
> fragmented by frequent allocation/deallocation of large arrays, causing a
> gradual degradation in machine performance over time. If you use large
> arrays in there, it may be better to allocate them beforehand and use
> "replace
array element" rather than allocating on the fly by using "build
> array" or having arrays built at the output of a loop.
>
In system.ini or autoexec.bat you set the the disk cache size to maximum
value. If you dont do this win95 will increase the disk cache size below the
RAM amount.... I had similar problems when trying to collect 200 ksamples/S
on P133 notebook for 20 sec, then it took ten minutes before writing to disk
stopped. You can check the mem useage by runing sysmon.exe.

Anders Björk
Analytical Chemistry
Royal Inst. of Technology
Stockholm
Sweden