Why is DAQ assistant delayed when recording analog voltage input of multiple channels?

[JJSett]

Hello,

I recently added several AI channels to my data acquisition system (from 2 to 8).  I was ready to start my experiment today and found out the hard way that my data was not being recorded when I thought it was....a description of my problem is below. 

Software/Hardware: My LabView (version 7.1) is simple: I am using DAQ Assistant to record 8 analog input voltages (Custom Voltage with Excitation analog input task) and am writing the data with Write To Measurement File Express VI.  It is set at continous sampling at 2,000 Hz for all, for 8,000 samples.  Hardware includes: DAQ card: PCI-MIO-16E-4; Chassis: SCXI-1001; Slot 1: SCXI-1520 Module with SCXI-1314 Terminal Block.

Problem: When pressing RUN, instead of running for 4 seconds the program runs for 14 seconds; I get no error messages.  My experiment consists of spending over an hour setting up, and then recording an impact that lasts less than a fraction of a second.  Because of this, I'd rather not try and guess when my program is actually recording my impact data.  I have tried analog triggering in the past but found it to be a little inconsistent and would rather collect some data before the impact process begins.

Questions: How can I correct this problem so that I know exactly when my program is recording the data (so I know when to start the impact process)?  And/or is there a way to visualize when the data is actually recording, not just when the program is running?

Thanks for your help!

Jake

[EEsRULEtheWORLD]

Hi, Jake.

I think the implementation of a reference trigger may solve your issue.  The cool thing about a reference trigger is that you can acquire pretrigger samples.  Data acquired up to the reference point is pretrigger data; data acquired after this reference point is posttrigger data.  A Reference Trigger establishes the reference point in a set of input samples.  You can configure this trigger to occur on a digital edge, a digital pattern, an analog edge, or when an analog signal enters or leaves a window.  Here is a great DevZone example that will give you an idea of how to implement a reference trigger into your code.  This will allow you to discard the data before the impact process begins.

In continuous acquisition mode, "Samples to Read" specifies the buffer size, not the number of samples to read.  If your goal is to read for exactly 4 seconds, then you need to change the acquisition mode to N samples.  In this case, the "Samples to Read" specifies the number of samples to read, and the program will acquire 4 seconds of data (8000 samples / 2000 samples/sec = 4 sec).

Let me know if you need any more information.  I hope you're having a great day!

[JJSett]

Hi Sara,

Thanks for the response.  I actually did some troubleshooting and it turns out the long delay was more due to the computer's memory being eaten up by Excel rather than a problem of LabVIEW's.  There is still a delay, but it is a manageable and mostly repeatable 1 second now. 

Other things I noticed that could be useful to others:

-When "Auto Zero" is turned on it increases the delay to approximately 2 seconds. 

-A lower (100 Hz) and higher (10,000 Hz) sampling frequency did not noticeably affect the delay. 

-Decreasing the number of channels from 8 to 3 seemed to decrease the delay from 1 to less than 0.5 seconds.

Thanks for the reference trigger info and I will definitely check that out.

Jake