Program Stalls Briefly causing test rig damage

Question

I am using LabView and a C-DAQ 9178 to control a hydraulic test rig.  The C-DAq utilizes a USB connection to the host computer running Windows 7. The program is a closed loop setup utilizing a PID subroutine to control each of the hydraulic valves and pump.  The control can be based on either cylinder position or load.  I am using a 9219 module to read the load cells, position indicators, and valve spool position.  A 9264 module takes care of the voltage outputs to the valves, relays, etc.The program will run great for extended periods of time (the machine is a fatigue tester, so it accumulates load cycles on a test sample over time).  But every once in a while, it will miss. And by miss, I mean it stalls.  The program is writing certain paramaters to a text file for review later.  What we see is a major delay in the time component of the data file.
It will look something like this.
Time:
604.150
604.200
604.250
604.300
604.524
604.554
604.575
The problem with this delay is that if the test subject is fairly stiff, the program stalls, causing the valve to stop and stay in whatever position was it's last signal (normally open).  This causes the cylinder to keep moving and normally results in unwanted damage of the test subject.  The program has checks built into that will shutdown the pump, center the valves, release the load, and unload the system pressure if the cylinder moves out of a given position or force range.  However, because the program stalls, these checks do not work until the program resumes and it is too late, the damage is done.
What can I do to eliminate this stalling problem?  Any help is greatly appreciated.
Thanks
Adam Kuiken
Senior Test Engineer
Arctic Cat Inc.

Answer 1

First, you need to determine if this is a Windows problem, or if your LV code is responsible.
If your data files are large, and you are building the text file using inefficient LV methods, you may be making an unexpected call to the memory manager. This is just one possibility -- there may be others. (Restructuring the code, with the file save in an independent loop, may aleviate the issue to some extent.)
If you have eliminated the possibility of a LV-based problem, then Windows could very possibly be the culprit (as suggested by others in this thread). Windows optimization *might* get you there, but there is always some uncertainty if Windows is in the equation. In testing, it might appear to be fine, but then Windows decides to scan the DVD drive, and you experience the failure again.
Side Note: Back in the LV 2007/2008 days, I had a similar intermittent Windows problem. It appeared to be related to the DVD drive. The solution was simply to put a DVD disk into the DVD drive. This prevented Windows from scanning the drive at unexpected times, solving the problem. 
If Windows system timing turns out to be the culprit, migrating to LV RT might be the easiest path forward. cRIO is a popular choice, but I personally prefer PXI or a desktop PC configured to run RT.
If your application doesn't require the user to engage other Windows applications (Excel, Word, etc), and additional hardware costs are the primary concern, one option is to configure your existing PC to run RT. This can be a cost-effective solution if there is some reluctance to purchasing additional cRIO or PXI hardware.
Here is a link to the requirements for running LV RT on a desktop PC:
http://www.ni.com/white-paper/8239/en/
We have successfully used LV RT on customized PC hardware when the application requirements exceeded the top-of-the line PXI controller, or when the cost for a capable PXI system has been prohibitive. In both of these situations, a custom LV RT PC makes good sense.
Anyway, good luck with your issue.
-- Dave
www.movimed.com - Custom Imaging Solutions