Questions regarding triggers and data acquisition

[Flonares]

Hello,

I have an external device that, when I am running my VI (I have attached a zip file with the VI and all subVIs, saved for version 20.0 - let me know if you need it saved to an earlier version), it will send a trigger (TTL, raising) to the PF0 port of the NI USB DAQ 6210. I have written the VI so that there is an option to start data acquisition with a start trigger (DAQmx "Start Digital Edge"). One complete run takes 40 seconds, and given the DAQ acquisition rate, it provides 40000 datapoints.

I have the trigger of my external device connected in paralell to an oscilloscope. The signal I use starts with a Lo signal, and when it starts running, has an active Hi signal that remains constant during operation. A Lo signal signals that it has ended. However, I have come to realize that my external device, halfway throught its operating run, goes Lo/Hi for a few microseconds.

For the first 10 runs, the DAQ runs perfectly - it measures all data accurately and reproducebly. However, without warning, it doesn´t collect any data for the first half (the data on the first half is literally zero, meaning it is not reading at all (there is no small noise, nothing. It´s just data padded with zeros) and suddenly, mid-range, it starts collecting data. Funnily enough, this corresponds to the Lo/Hi jump I observed on the Oscilloscope.

At first, I suspected it could have been a mistake from my data processing routines. But by analyzing the raw data from the DAQ, I noticed I had 19200 points, which is roughly half of the points, and coincides with the aforementions Lo/Hi jump (which itself is located on the crossover between the two QCL´s of my laser). The software-based data aquisition works fine all over the range, but the data obtained is always shifted timewise, so analysis of two independent data sets requires a bit of manipulation to make them overlap.

A picture of the wiring at the DAQ connectors is also provided.

My questions are:
- If the VI is set so that it starts collecting with a Start Digital Trigger, and since there are no Digital Reference Triggers, what would be the consequences of having a second trigger pulse during data acquisition?
- Is my code not properly designed for such a data aquisition setup? I don´t understand why the DAQ stopped responding to the initial trigger pulse, when I can see it clearly in the oscilloscope.
- What could lead the DAQ to not acquire the first half of the data at all, despite collecting data previously correctly?

Please, feel free to ask any questions deemed relevant to understand this issue - I will diligently answer them to the best of my abilities. I thank you all in advance for your help.

Cheers,
Fl0

[Kevin_Price]

---

My questions are:
- If the VI is set so that it starts collecting with a Start Digital Trigger, and since there are no Digital Reference Triggers, what would be the consequences of having a second trigger pulse during data acquisition?
- Is my code not properly designed for such a data aquisition setup? I don´t understand why the DAQ stopped responding to the initial trigger pulse, when I can see it clearly in the oscilloscope.
- What could lead the DAQ to not acquire the first half of the data at all, despite collecting data previously correctly?

1. The undesired 2nd "trigger pulse" will be ignored.   (This assumes that your system startup timing can ensure that the task was armed and ready before the desired 1st rising edge occurs.)   A continuous task won't re-arm for another trigger until you stop and re-start the task.

2. Maybe the aforementioned system startup timing isn't completely consistent and reliable.  Perhaps the initial low->high transition happens before your task is started and its trigger system is armed.

3. Race condition between your software execution timing and your external equipment startup timing?

Additionally, I find your DAQ read loop to be, well, troubling.

You don't specify a # samples to read from the task each iteration of your loop so the default behavior is to read whatever # is available.  The loop has no obvious delays (though I have no idea what your special MIRcatSDK function might do), so you are iterating as fast as possible and appending waveform data in software maybe 1 or 2 samples at a time.   That's very inefficient.   I'd recommend retrieving at least 1/10 sec of samples each iteration.  At 1 kHz sampling, that's at least 100 samples per read.

-Kevin P