Scott,
This advice probably won't solve your problem, but I'd like to offer a suggestion. When you mention a 3.5 second data acq freezeup, I assume you're using traditional NI-DAQ to perform a buffered read requesting a bunch of data, and it takes 3.5 seconds for that much new data to accumulate in the read buffer. I'd suggest trying to avoid this freezeup.
1. Thought 1: try DAQmx for the data acq. It's multi-threaded and will yield CPU as needed.
2. Thought 2: Those data acq freezeups used to cause me grief. So I made it a habit never to request data that the daq driver needs to wait for. I would instead query the # of available points in a loop including a short Wait (msec) delay. I wouldn't ask to read N points until seeing that at least N were available. This way the DAQ call doesn't cause a freezeup.
One way to query the # of available points in traditional NI-DAQ is to call 'AI Read' while requesting 0 samples. This will return immediately with no data, but another of its outputs tells how many samples are backlogged.
Good luck with the real problem too!
-Kevin P.
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
