Henrik, thanks for the response. Things are working a bit better now. I think there may be several things going on. The wiring, cable connections, and grounding seem to be fine with the possible exception of a USB extension cable, which we have removed. The laptop running the LabVIEW application was trying to download updates, and was running slower than usual. Stopping that process and adjusting execution priorities seems to have fixed the problem. Now I just want to make sure that it doesn't happen in the future or at least to detect the problem if it does recur. The strange thing is that the data seemed to go bad on different channels from the same NI 9237 card (and recover) at different times. I think we were getting the -200279 buffer overwrite error, but the program wasn't actually hitting the DAQmx Read vi, because some logic upstream was checking if samples were available using a property node (which incidentally did not output the error code; it just returned zero samples available). I will work on some software fixes, including allowing overwrites when necessary, more complete error detection, and possibly isolate the read function by moving a downstream lowpass filter into a separate loop. Another interesting thing to note is that we could unplug the analog inputs from our NI 9237 card and get similar data, except that the sign was reversed. In these cases, it appears to be getting a max or min A-to-D conversion. With the load cell cable unplugged, the system does not appear to automatically detect a missing instrument. I would have expected to get an error from an open circuit detection. One other safeguard to add to the program would be to test the analog input value to see if it is out of the expected range. Sometimes the bad data has been within the expected range, but hopefully the above changes will prevent/detect those problems.
