LabVIEW
Windows processes go wild during PCMCIA DAQ + logging
This one may fit under the DAQ group, but the app is in LabVIEW so I thought I'd give thsi a try. I usually do the answering around here, but this time I'm in a bind.
One of our customers is experiencing a serious problem during data logging that we have been unable to isolate and solve.
They are running on Windows 2000 and 98 platforms, LabVIEW 6.1, NIDAQ 6.9.3.
They have a PCMCIA 6024 DAQCard sacnning continuously at 100 scans/sec across up to 8 channels. There is a periodic (30 sec interval) single line of text being appended to a log file. Meanwhile a ~20 minute average is being compiled with points at 0.5 sec intervals.
About halfway through the second 20 minute average, the system processes go w
ild. It appears to be a freeze at first glance, but it is actually something different.
Looking at the Task Manager reveals that two processes have taken over 100% of the processor.
System takes about 70-75%
winlogon.exe takes the rest
LabVIEW is left with nothing and the whole system is VERY sluggish. Even once the LabVIEW application is shut down, the slugishness persists. If LabVIEW (or the build exe) is forced to quit with the task manager, a blue screen (BSOD) happens. No doubt that is sparked by NIDAQ and its buffers or IRQ having a heart attack.
I read a Knowledgebase article entitled "Software Hangs When Performing High Speed Externally Clocked Acquisition with PCMCIA Card". We're not externally clocked but it mentions that internally clocked acquisitions running at under 1kHz are also set to "generate interrupt every sample". Do you believe that changing it to "generate interrupt every half-fifo" will solve the problem?
The target hardware is in the field
now so I cannot try that solution. I want to be able to give my customer something solid. Any ideas?
One of our customers is experiencing a serious problem during data logging that we have been unable to isolate and solve.
They are running on Windows 2000 and 98 platforms, LabVIEW 6.1, NIDAQ 6.9.3.
They have a PCMCIA 6024 DAQCard sacnning continuously at 100 scans/sec across up to 8 channels. There is a periodic (30 sec interval) single line of text being appended to a log file. Meanwhile a ~20 minute average is being compiled with points at 0.5 sec intervals.
About halfway through the second 20 minute average, the system processes go w
ild. It appears to be a freeze at first glance, but it is actually something different.
Looking at the Task Manager reveals that two processes have taken over 100% of the processor.
System takes about 70-75%
winlogon.exe takes the rest
LabVIEW is left with nothing and the whole system is VERY sluggish. Even once the LabVIEW application is shut down, the slugishness persists. If LabVIEW (or the build exe) is forced to quit with the task manager, a blue screen (BSOD) happens. No doubt that is sparked by NIDAQ and its buffers or IRQ having a heart attack.
I read a Knowledgebase article entitled "Software Hangs When Performing High Speed Externally Clocked Acquisition with PCMCIA Card". We're not externally clocked but it mentions that internally clocked acquisitions running at under 1kHz are also set to "generate interrupt every sample". Do you believe that changing it to "generate interrupt every half-fifo" will solve the problem?
The target hardware is in the field
now so I cannot try that solution. I want to be able to give my customer something solid. Any ideas?
Memory is fine >70 MB free out of 256 total. No leaks detected. Also, the processor sits at around 30% when the app is running OK.
I'm trying it with simulated DAQ now.
Thanks,
Dan
I'm trying it with simulated DAQ now.
Thanks,
Dan
It did turn out to be the DAQ process after all. Changing the settings for the interrupts solved the problem. The mystery is still the fact that even without the fix, the system was running OK for several months. We are officially blaming the Windows updates that have been appearing fast & furious lately.
Thanks!
Thanks!
