Hardware timed CI/CO, AI/AO operation with specific order of execution

[ch.pi3]

Hello everyone,

I am working with a NI USB-6361 data acquisition device and I am trying to write a 2011 LabView program that sends a signal to my output device and reads back several values from various measurement devices. I have a voltage ramp signal (in an array format), and I need to sequentially send elements of this array to my AO device with very exact timing (ideally hardware timed). As soon as the value is written to the AO device, I need my AI and CI tasks to record any available data and my DO task to send a single pulse before the next array element is sent to the AO device. This all needs to be very precisely timed such that if I were to perform a measurement involving 1000 points in my ramp array with a timing of 1000Hz, the program will take exactly 1s to run (minus any overhead caused in the initialization and closing of the tasks), and would produce a data array consisting of 1000 AI and CI measurements. I had initially tried to accomplish this using a sequence structure inside a software timed loop, but because I will be dealing with multiple AI and CI channels and large data arrays, this turned out to be unreasonably slow. The other danger I fear I might run into is the case in which the LabView program runs slower than the data acquisition process itself, thus causing data to be overwritten in the buffer and measurements being lost. 

I have not spent much time working with timing and syncronization procedures, so I apologize if this is a rather naive question - I'm having difficulty reconciling inherent software limitions and execution order with the hardware timing. What is the best way of accomplishing this? I can only think of two reasonable approaches to the problem:

1) Should I try to trigger my CI and AI tasks to run on the completion of the AO task (and if so, how)?

2) Should I have the CI and AI tasks run on a separate clock with a slight initial start delay as to offset these tasks so they reliably occur after each AO value is sent to my device? 

Eventually I will build an identical program for a real-time PXIe-8100 embedded controller. Would the approach be any different in this case? 

Thank you in advance for your response.

[Kevin_Price · Accepted solution]

I can give you an outline of the steps you'll need, but be prepared to spend a little time experimenting and troubleshooting some of these individual pieces before putting them all together.

First, an X-series 63xx device provides all the capability you need to accomplish very precise sync in hardware.  When you later switch to a Real-Time controller, you should include an X-series device in the chassis to maintain this hardware capability.

Second, 1 kHz is not even a challenge for LabVIEW to keep up with your hardware, even with the lesser-powered RT controller.  You just need to program the DAQmx tasks to let the hardware & driver do the heavy lifting.

1. I would dedicate one counter from the 6361 to generate the shared clock for the other DAQmx tasks.  I tend to create a clock with 90-95% duty cycle for this kind of stimulus-response application to allow maximum response & stabilization time.  Generate the stimulus on the leading edge of the clock and acquire response data on the trailing edge -- just barely before the next stimulus sample.  Let's call this the Clock task.

2. Configure a buffered AO task that uses the Clock output as its sample clock. Configure the polarity to be sensitive to the leading edge (commonly this will be a rising edge).   Start the AO task *before* starting the Clock task.

3. Configure the AI and CI tasks to use the Clock output as their sample clocks.  Configure the polarity to be sensitive to the trailing edge.  Start the AI and CI tasks *before* starting the Clock task.

4. The output pulse should be a counter output task, configured to generate a retriggerable single pulse.  Configure it to use the Clock output's leading edge as the trigger signal.  Define both the "low time" and the "initial delay" to equal the precise <1 msec delay you want to make sure that you get the same timing on every trigger.  Be sure the high time allows the full pulse to fit within your Clock period.

5. Look into the "producer consumer" pattern so that you can separate your data processing from your data acq.  You should stream the data to file continuously rather than accumulating it in large arrays.  File writing speed can be unpredictable, this is why file access needs to be in a separate loop that acts as a consumer of the data that the data acq loop produces.  When you switch over to Real Time, assign a lower priority to the file writing process.

-Kevin P

[ch.pi3]

Thank you very much for you advice - this is all very useful. I've made a smaller test VI to try out some of these routines before implementing them into a more comprehensive program. As you suggested, I have a continous pulse train that controls the timing of my AO, AI, and CI tasks. When I run the VI and look at the trace on my oscilloscope, I notice that the AO ramp function often gets written to the device multiple times before the task is stopped at an arbitrary location (see IMAG1514.jpg: this ramp should consist of 10 samples that are sent to the AO channel at the clock frequency of 10000Hz). How can I get the program to finish once the 10 AO samples are written to my device? I had tried to set the clock pulse to finite samples (and wired the desired number of points in my ramp to the clock's DAQmx timing VI), but this returned the following error:

"Requested value is not a supported value for this property. The property value may be invalid because it conflicts with another property.

Property: SampQuant.SampMode
Requested Value: Finite Samples
You Can Select: Continuous Samples"

I imagine this is probably trivially easy to solve, but in all my playing around, I haven't managed to find a solution to the problem.

[ch.pi3]

Never mind, I figured out what I had done wrong. I was wanting to use the Dev1/freqout pin as the counter for my clock pulse train, but did not realize that this could not be set to finite samples mode (and also does not support a duty cycle != 0.5). I am now using Dev1/ctr0 as my clock device, and everything works perfectly. Thank you very much for your help, Kevin.