Labview pauses

[pete king]

I have developed a LabView ver. 7 program which inputs digital data at about 1MByte/sec from a NI 6534 DIO card and writes it to hard drive via. USB-2. I am running it under Win. XP and the application has to run for hours without missing any data.

The VI will freeze or pause every 1 hr, 3 min and about 20 seconds. It stays paused for 10 -15 seconds, long enough to cause a DIO error, either 10800, 10802 or 10845 each time it pauses.

I have run a similar program under Win 98 in the past with out this problem. I have searched for programs running in the background such as firewalls, antivirus, etc and uninstalled all that I can find.

The first occurrence of the pause occurs at a random time after starting LV and then at 01:03:20 thereafter so It does not appear to be LV related.
Has anyone seen this behavior before?

[LV_Pro]

One possibility may be disk indexing in WindowsXP. If it is turned on the system may want to update its date periodically.


Putnam Monroe

[LV_Pro]

To turn it off, right click on the various drives under "My Computer" select "properties" at the bottom of the pull down and when that opens there is a check box at the bottom that allows selecting indexing (or not).

Putnam Monroe

[RobCole]

A 10845 error (or 10846 for that matter) can be caused by a DAQ device acquiring data faster than you are taking it out of the buffer. Eventually you get a buffer overrun. The system then resets itself and flushes the buffer to start again. You can check this by looking at the AvailSampPerChan property in a DAQmx Read property node (if using DAQmx) or the Scan Backlog output (if using traditional DAQ).

I ran mine to a chart on the front of the VI so I could watch it over time and found that I was overrunning my buffer. So I sped up taking data out of the buffer.

As a possible (but not probable) other problem: You might want to profile the program and see if you have a memory leak somewhere. If you have a slow memory leak (can be caused by many things including references that are opened and not closed), then the program will slowly use more memory and eventually crash.

Hope you can get it up and running. And let us know what you find out.

Rob

[m3nth]

Memory leak or not, that sounds like a disk caching issue. I would recommend Robert's advice and also using task manager to watch your Virtual Memory size and page fault delta. A lot of similiar problems like this that I have had (not necessarily with LabVIEW, but in general), are when Windows tries to expand the VM size for an app, page faults go up (you can note that in the PF delta column) and then there's this large delay where seemingly nothing happens.

Also, in task manager sometimes you will need to enable the appropriate columns if they aren't on by default... I usually look at memory, peak memory, page faults, page fault delta and cpu time to pin down the culprits.

One more thing I just remembered is that I have specifically had these problems with low disk space which makes Windows go crazy when it tries to increase the VM size. This is not always as obvious as it might seem and can happen when a lot of temporary junk is created on a disk with low storage size... just make sure you got lots of gigabytes free 🙂 (it's usually on the order of less than a hundred megs when my various configurations of Windows start to crap out)

Good luck.

[unclebump]

Another option could be to write to a USB or solid state hard drive. These should have much faster write times. Are you writing the data from the same loop that is acquiring the data?? Maybe you could write the data into a queue and pass it to another loop that writes it to disk.

[pete king]

Thanks for all the suggestions.
Disk indexing is not enabled on either drive.
There may be a problem with page faults and/or VM. I don’t know enough about them to evaluate the indications I am getting. Here is the situation:

Drive C:\ is a 4 GB flash memory
Drive D:\ is a 120 GB external USB-2 hard drive used only for data storage.
The Processor is a 1.6 GHz Pentium M on a PC-104+ board.
512 MB RAM

I ran the task manager as m3nth suggested and would like advice as to what the results mean.
While running, task manager indicates the following for my LV program:

Memory usage 101,464 k remains constant
PK mem. Usage 107,540 k remains constant
Page Faults 727,952 k constantly increasing
PF delta 0 to 13 k constantly changing
VM size 95,500 k remains constant

In my LV program, DIO buffer size is 15 M Scans at 2 bytes/ scan
I read the DIO buffer 3,151,872 scans at a time only after backlog indicates there are that many in the buffer.

For XP:
VM is set up as follows:
“system managed size” is selected
Total paging file size for all drives currently allocated = 719 MB
Drive C has about 1 GB free memory.

Thanks for the help,
Pete King

[m3nth]

Ok... this is some good info on your system.

Off the top of my head, I am now curious as to how you're storing your data that is acquired. How are you buffering it and how are you saving it to disk. Are you building arrays at run time?

A constantly increasing page fault total usually is an indicator of dynamic memory allocation at run-time. Your program may also be deallocating the memory which could possibly be why your memory sizes don't change much. LabVIEW would be doing this all for you based on your program design, which may be the cause of the problem.

I believe you said you had LV version 6... I'm not sure what version it is available in but there is a tool in the latest version that will show where data buffering takes place--where data on your wires is being copied. As a general rule, it's best to avoid making copies of the data as much as possible.

There is also an article by NI on how to set up your data structures and arrays when using them in loops so as to help LabVIEW manage the data as efficiently as possible. I would definitely recommend reading that and seeing how your program matches up to the suggestions made in the article. If you have poor implementation of a data array inside of an acquisition loop it can cause quite a bit of dynamic memory allocation/deallocation which in turn can cause random unforseen delays due to interaction with the OS when it tries to allocate that memory.

[Ben]

Just a quick comment:

The Page faluting could be normal if there are files being writen.

If the VM is stable I would doubt memory leaks etc.

The periodic nature of the disturbance is interesting. What does the CPU do at the time in the interuption?

If you look at the preccess at teh time of the event, who is getting top CPU time?

Are an of the locals drives served to other machines?

Have you tried pulling the network cable?

ET may be trying to phone home.

Ben

Message Edited by Ben on 05-18-2005 07:11 AM

[unclebump]

Have you got this option set??

http://zone.ni.com/devzone/conceptd.nsf/webmain/28A6979ECA9A0CAF862569050053D92D