08-01-2007 06:46 AM - edited 08-01-2007 06:46 AM
Message Edited by mr_nice on 08-01-2007 06:47 AM
08-01-2007 07:28 AM
First, thanks for presenting your question clearly -- "a problem well defined is a problem half solved."
Second, good news, there are several possible options available to you. Best choice may depend on some further details of your app. Some thoughts in no particular order:
1. You say the "trigger" signal transitions from low to high to start the acquisition and remains high throughout the acquisition? Should the acquisition end when it goes back low? If so, how long before it might go back to high again? What I'm driving at is that you may find that "pause triggering" is a more appropriate choice. It functions by performing acquisition while the trigger signal is high.
2. How much data are you collecting all together? Is it important to read out a little at a time for real-time display and/or analysis?
3. You might look into the idea of a "state machine". One state would be monitoring the AI task to see if the trigger has occurred yet -- one way to do this is to query the DAQmx Read property node for the property named something like 'Total Samples Acquired". Another state would be to collect data after the trigger event has been detected.
4. You might consider using a very small timeout value on DAQmx Read. If the requested samples aren't yet available, you won't get stuck hanging there so long and can service other code.
5. You could have an independent loop that looks for the "abort" file so it can run in parallel with the data acq task.
-Kevin P.
08-01-2007 11:44 AM