Sick Windows 7 yields error -200279

[Ken_Brooks]

I do my LabVIEW 2009 development on two systems: one at home, and one at the lab. The program is a complex DAQ program using analog and digital input and output, four tasks running in sync. But it has been working for a long time. About a week ago on the home system it got sick: run the program, start the tasks, in about 10 to 15 seconds it would pop up with error -200279, "samples no longer available". In other words, the program couldn't keep up with the flow of data.

Experiments tried: significant changes to the sampling rate, and to the number of samples read at one time. Result: the error does not go away, but the time until it occurs changes with these settings. Within each set of values for these settings, the time until error is quite consistent!

Other experiments tried: Commenting out the subVI that is using the lion's share of the time, according to the profiling tools. I also used my source control system to go back in time about three weeks to a program that was known to handle its timing quite well. It didn't work! And then, to top it off, I went into the lab and tried the newest program there. It worked!

So my system has grown sick, quite recently. No one who works on this machine claims to have downloaded or updated anything of significance in that timeframe.

I'm at a loss. Can anyone suggest some places, short of reinstalling the whole machine from scratch, to start looking? Or how to do better diagnosis?

Thanks much,
Ken

[Ben]

That error indicates you are not getting back to the I/O operation fast enough to get and values that have been lost or over-written.

If say it used to wok but not now then something is getting in the way of allow the LV tasks to run.

I suspect virus or virus check software.

Use the Windows Taks manager to monitor the CPU whil ehte test is running and figure out who is dominating your CPU. If you don' recognize the name, I'd just start killing things until LV iss getting the top CPU. Then figure out what it was you killed and goolge them to figure out what they are and where they came from.

Ben

[Ken_Brooks]

Thanks, Ben.

Surprise, surprise! I looked into this further, using your suggestions, and discovered that it is not a CPU limitation problem! Looking in the Processes screen, I see that LabVIEW is first in CPU usage, at 3-4%. Max 5%. The runner-up is Spybot, at 1%. Killing it has no effect on the problem.

As before, I see a consistent, fairly accurately timed 8 second cycle. Once every 8 second I have a failure, from which I can recover. Looking in the Performance screen, I see that CPU usage there is normally a 2-3%, but spikes to 6-7% in the reading following a failure. Fairly consistently. If I stop LabVIEW there is no 8 second cyclical behavior in the Performance screen.

This CPU is WAY more than adequate for this task. An Intel i5 quad core CPU at 2.67 GHz with 4 GB RAM.  Something else is causing DAQ to lag, and I can scarcely imagine what. Unless DAQmx itself is to blame?

Ken