LabVIEW
LabVIEW stores data to disk without being told to
Is it possible that the OS is increasing the swap file size (What is you OS?) due to increasing memory demands? Try setting a minimum swap file size in the OS configuration. You should pick a value for the minimum size slightly above the size after a few runs of the program.
You might also want to carefully inspect your code to eliminate unnecessary extra data copies.
You might also want to carefully inspect your code to eliminate unnecessary extra data copies.
mhtl wrote:
> I am using LabVIEW 7.0 with a SCXI 1000 chassi which has an 1100
> module for thermocouple measurements and an 1180 direct feed through.
> The DA card is a PCI-6024E.
>
> I have developed an application that is acquiring a total of 25
> channels at a rate of 5000 hz using Daqmx. I am using continuous data
> acquisition and then a gate/trigger to sort the data out and
> process/chart it. I use the daqmx buffer configure to set the input
> buffer to 400 000 since I noticed without this the system misses some
> data since it is monitoring a cyclical system that cycles once every
> 3.0 seconds. I then read the data using a 1D waveform read, N
> channels N samples daqmx subvi.
>
> The computer is a pentium IV 2.4 GHz with 500 MB of ram. It isn't
> connected to a network and is dedicated soley to running this program.
>
> The problem I am seeing is that if I reboot the computer, the first
> two or three times I run the program it seems to store the data to
> disk and cause extremely long processing times of up to 100 seconds
> for one process cycle of monitoring - 3.0 seconds. The reason I think
> it is storing to disk is that I see the hard drive light come on and
> stay on while this happens.
>
> Once I have stopped and started the program two or three times, it
> works flawlessly without any indication it is reading or writing to
> disk.
That is not LabVIEW but the Windows memory swapping. As you start the
data acquisition you tell NI-DAQ to allocate an intermediate buffer of
about 25 * 400000 * 2 bytes = 20'000'000 bytes. Then in LabVIEW you read
that data in 3 second intervals = 3 * 5000 * 25 * 4 bytes = 1.5MB and
this data gets several times allocated for the display graph and
possibly several more copies for your diagram wiring depending on how
you did it. So LabVIEW requests a lot of memory from Windows at startup
and Windows will start to swap out some if its own less used libraries.
After the first few iterations the memory situation has settled down and
as long as you don't make another memory intense application to come in
the foreground, this will stay like that.
Expect trying to reduce the different buffers and possibly review your
diagram for some inefficient wiring, the only other solution is to
install even more RAM into your computer if you can.
Rolf Kalbermatter
> I am using LabVIEW 7.0 with a SCXI 1000 chassi which has an 1100
> module for thermocouple measurements and an 1180 direct feed through.
> The DA card is a PCI-6024E.
>
> I have developed an application that is acquiring a total of 25
> channels at a rate of 5000 hz using Daqmx. I am using continuous data
> acquisition and then a gate/trigger to sort the data out and
> process/chart it. I use the daqmx buffer configure to set the input
> buffer to 400 000 since I noticed without this the system misses some
> data since it is monitoring a cyclical system that cycles once every
> 3.0 seconds. I then read the data using a 1D waveform read, N
> channels N samples daqmx subvi.
>
> The computer is a pentium IV 2.4 GHz with 500 MB of ram. It isn't
> connected to a network and is dedicated soley to running this program.
>
> The problem I am seeing is that if I reboot the computer, the first
> two or three times I run the program it seems to store the data to
> disk and cause extremely long processing times of up to 100 seconds
> for one process cycle of monitoring - 3.0 seconds. The reason I think
> it is storing to disk is that I see the hard drive light come on and
> stay on while this happens.
>
> Once I have stopped and started the program two or three times, it
> works flawlessly without any indication it is reading or writing to
> disk.
That is not LabVIEW but the Windows memory swapping. As you start the
data acquisition you tell NI-DAQ to allocate an intermediate buffer of
about 25 * 400000 * 2 bytes = 20'000'000 bytes. Then in LabVIEW you read
that data in 3 second intervals = 3 * 5000 * 25 * 4 bytes = 1.5MB and
this data gets several times allocated for the display graph and
possibly several more copies for your diagram wiring depending on how
you did it. So LabVIEW requests a lot of memory from Windows at startup
and Windows will start to swap out some if its own less used libraries.
After the first few iterations the memory situation has settled down and
as long as you don't make another memory intense application to come in
the foreground, this will stay like that.
Expect trying to reduce the different buffers and possibly review your
diagram for some inefficient wiring, the only other solution is to
install even more RAM into your computer if you can.
Rolf Kalbermatter
Swapping memory is relatively fast unless the OS needs to constantly incremetally grow the swap file. Above, I have mentioned to make sure the swapfile does not need to be dynamically resized.
Here is a relevant aplication note:
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/9c654bf862c049c786256cc4005ea4ad?O...
An excellent writeup on issues related to dealing with large data sets is the following document:
Managing Large Data Sets in LabVIEW.
This is certainly something you should read.
Here is a relevant aplication note:
http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/9c654bf862c049c786256cc4005ea4ad?O...
An excellent writeup on issues related to dealing with large data sets is the following document:
Managing Large Data Sets in LabVIEW.
This is certainly something you should read.
