Zach,
Since you have created the DAQ tasks elsewhere, we cannot see how you have them set up. Continually Starting and Stopping tasks may be slower than setting up a continuous task and letting it run.
You did not indicate what DAQ hardware you are using. Often it is better to let the clock in the DAQ device set the timing rather than relying on software timing. The pressure loop reads 1000 samples at a time and averages them. If you are not sampling at 2000 S/s or faster, the loop will finish late because of waiting for data. In both DAQ loops you are not using the timing information. Acquire the data as arrays rather than waveforms.
The Dequeue functions in the bottom loop have no timeouts so that loop will not iterate until all three queues have data. Since the Pressure loop runs faster than the RTD loop, the pressure queue will slowly fill up.
The top and bottom loops compete for the data. The Preview Queue Element does not remove data from the queue, but the Dequeue Element functions in the bottom loop does. If the data is removed form the queue before the top loop looks at it, it will never get saved. With your setup there is no way to assure that you get all the data or that you do not read and save the same data more than once.
You have nothing set up to stop any of the loops. Are you using the Abort Button to stop your VI? If so, STOP! Another aprticpant on the Forums has stated: "Using the Abort button to stop a VI is like using a tree to stop a car. It works but may have unintended consquences!" Things like closing files, releasing queues, closing DAQ tasks, and other things cannot happen when the program is aborted. You do not shut off your computer by pulling the plug. You should shut down your program in an orderly manner also.
OK. I have pointed out some of the things which may keep your program from running as you wish. What can you do about them?
1. You probably do not need timed loops. Regular while loop should be good enough.
2. Put a Stop button on the front panel. Put the terminal in the indicator loop (at the bottom) and connect it to a Send Notification function and to the loop condition terminal (stop sign). Put Wait on Notification functions in each of the other loops. Put a timeout shorter than the minimum loop time on each one so the lops can run.
3. See comments above about hardware timing of DAQ Reads.
4. Use Dequeue timeouts to set the loop timing in the loop where the data is used. Also make sure that all the data gets dequeued. You need to think about your overall timing requirements and what the bottlenecks are. Unless you expect this system to grow to much larger dat sets, I would probably acquire ALL the data (Pressure and RTD) at the same rate and reduce the amount displayed by averaging as you are doing for the pressure data now. If you want different final data rates, simply average different amounts of the data.
5. It might be worthwhile to learn how state machines work. The display, averaging, and file saves could be managed in one loop by a simple state machine while allowing more flexibility in timing.
6. Another good reason to consider a state machine is that the initialization and shutdown processes can easily be managed in corresponding states. At present you are not doing anything with errors. A state machine would allow you to handle errors (such as the user canceling the file selection) without shutting down the program.
Lynn
