Data acquisition from NI 9215 with external trigger signal sync

[DanFreeze]

Hello,

I am fairly unexperienced with LabView and I have seen a few topics in the Forums that get close to my problem, but I have been unable to successfully implement any of the discussed solutions. In some cases, they simply go over my head.

My problem is this: I am reading in three signals on an NI 9215 analog voltage module. The cRIO that the module is installed in is also used to control other parts of the experiment, so I am using a separate VI for this particular data acquisition issue and I do not want to change where the other VIs get their timing signal from. The first signal comes from a timing box that runs at a user-selected frequency, outputting at TTL signal, i.e. a 1.5 V peak square wave. The second signal comes from a photodiode (PD) and the third one is the monitoring signal from a CCD camera. I want to record the PD and camera signal at a frequency of 2000 Hz at the same point in time. My idea was to use the TTL signal as a sync trigger, to trigger the acquisition of one sample of the PD and the camera each at a rate of 2000 Hz. I have written the attached VI so far and added screenshots below.

1. I have not been able to figure out how to use the analog measured TTL signal as a trigger for data acquisition. I saw in some posts that maybe it could be used to sync the sample clock directly, or that it could somehow be used as a continuous trigger for collecting one sample on each pulse. But the explanations given in those posts have been insufficient for me to replicate that successfully. Probably doesn't help that this runs on LabView 2014 on a lab computer, so I haven't been able to open example VIs from later versions. The NI 9215 also does not seem to support analog triggers, so maybe I have to convert it to a digital signal first?
2. In its current implementation I can tell it to sample at a certain frequency, but the number of samples is ignored. Why do I need a for loop instead of a while loop i this case, if I am telling the sampling clock how many samples it should acquire?
3. Ideally, I would like for this VI to start, wait for the first trigger signal, and then collect data synced to the trigger signal until either a certain number of samples has been taken or the trigger signal disappears. In the latter case I could stop execution manually as long as it stops collecting data ad writes the buffered data out to a file before shutting down. Alternatively, if the system waits for the first trigger pulse and then simply collects for a certain number of samples at a fixed sampling frequency, that should also work but is less ideal.

In the attached VI, the two signals I want to record are in the channels:

whereas the TTL signal I want to use for triggering is on cDAQ9185-211CCF9Mod4/ai0

Could someone help me with the implementation of this and tell where I am going wrong?

Cheers

Dan

[mcduff]

From your screenshots, it looks like you are programming using the DAQmx API, no FPGA programming for your CRIO.

The fix is relatively easy. Either connect or split your TTL signal, one part of the split needs to go to one of the PFI inputs on your 9215. Use this PFI terminal as your Digital Trigger. Look in the DAQmx palette for the trigger function or even better LabVIEW 2014 has DAQmx examples (Look in the example finder), look in the analog input examples to show you how to setup the digital trigger. Note you don't need to split your TTL signal if you don't want to digitize it.

[DanFreeze]

Thank you for the quick response.

Yes, I am not using FPGA programming at the moment. Is that recommended for such an application?

The NI 9215 module itself does not have a PFI input, the c-DAQ 9185 does have one. Could that be used without altering the behavior of the other modules that are installed?

Edit: I connected the TTl signal to the PFI0 of the cDAQ and I can pick it as an input for a digital trigger. Now the VI only writes out one sample and the sampling speed seems to be based on the clock. What do I have to change to acquire one sample per trigger pulse, write that all out at the end, and make sure I only collect a certain amount of samples?

Cheers

Dan

[mcduff]

---

@DanFreeze wrote:

Yes, I am not using FPGA programming at the moment. Is that recommended for such an application?

---

I would NOT recommend it; a lot more work for FPGA along with high level programming experience. DAQmx is probably sufficient for your needs.

---

@DanFreeze wrote:

Thank you for the quick response.

The NI 9215 module itself does not have a PFI input, the c-DAQ 9185 does have one. Could that be used without altering the behavior of the other modules that are installed?

---

Yes that PFI input would work. I did not look up the specs of the 9215 when responding previously.

---

@DanFreeze wrote:

Edit: I connected the TTl signal to the PFI0 of the cDAQ and I can pick it as an input for a digital trigger. Now the VI only writes out one sample and the sampling speed seems to be based on the clock. What do I have to change to acquire one sample per trigger pulse, write that all out at the end, and make sure I only collect a certain amount of samples?

---

In your picture you are only acquiring 1 sample from each input. Change the acquisition mode to NChan NSamples to acquire a triggered array of samples. This would be analogous to an oscilloscope. You will have change your data handling from single point to an array from the Read function.

If your want to take only a single point for each acquisition you will need to restart your task and wait for the next trigger. All you need to do is put a stop and start task, in that order, in you loop after acquiring a single point.

Once again look in the Example Finder for Finite Acquisition under Analog Input for good working examples.

[DanFreeze]

So, what I am doing now is shown in the image below. Did I interpret your suggestions correctly?

I do only want to collect one sample per trigger, as in continuous triggered data logging, not an oscilloscope mode. However, for some reason this setup still samples when there is no trigger signal on the PFI at a constant frequency of 6.3 Hz, which does not correspond to any setting I impose. Do you have any idea why that might be happening?

[Kevin_Price · Accepted solution]

To get 1 sample per external pulse, it'll be simpler to use the external TTL signal as a *sample clock* rather than as a trigger.   These are treated as *very* distinct things under DAQmx terminology.

Here is very incomplete code to illustrate the basic idea of such an approach.  If the external signal has an unknown or variable rate, set the 'nominal rate' to be the maximum rate you'd expect.

-Kevin P

[mcduff]

Just guessing here since you only show a portion of your VI, in the future it is best to attach the VI and back save it to an older version of LabVIEW, like 2020.

The DAQmx Read function has a timeout function that you do not set. To wait forever for a trigger, set it to -1. Note that this may/will prevent your loop from exiting if there is no trigger. I am guessing your read timeouts.

EDIT: Go with Kevin's solution, much simpler to implement.

[DanFreeze]

Thank you for all the suggestions. I implemented Kevin's solution at it seems to work. I attached the VI and pictures of it below. 

I can now tell it to take 2000 samples and it will stop after those 2000 samples. It also only seems to collect data once the TTL signal is present. I have one more question: is there a way to ascertain the exact time at which a given sample was recorded? Currently I have this manual work-around where I construct a time vector after the fact to plot the voltage values against time. But that assumes that I know the trigger signal exactly and I cannot double check if the values are actually collected at the correct time interval. Is there a way to extract time stamps associated with each sample? My goal is a sample frequency of 2000 Hz, so it does not have to be more precise than +-10microseconds.

The "true sample rate" indicator also still shows what I set, but I'd like to see what the sampling frequency is based on the input from the TTL signal.

Cheers

Dan

[Kevin_Price]

---

...Is there a way to extract time stamps associated with each sample? 

---

With just the 9215 and analog task, no.

By programming an additional task using an internal counter built into your cDAQ chassis, yes.

The job is substantially simpler if you know the external signal will be at a constant rate throughout a given run.  Look up the Counter Input shipping example that illustrates on-demand frequency measurement to get started.

If the rate can vary, you'd need to do something more like a continuous period measurement, then the relative sample timestamps would be a cumulative sum of all the periods up to that point.  Two things worthy of further note:

• it takes 2 pulses on your PFI terminal to produce the 1st full period measurement.  That relative time should be assigned to the 2nd AI sample.  The first AI sample should be assigned relative time = 0.
• With newer NI DAQ devices, the 1st period value captured will be your 1st *full* period.  With older ones, the 1st value captured would be a partial period, measuring the time from when the counter task started until the 1st PFI pulse arrived.   To test which era you have, keep re-running the example program while measuring a known-constant frequency.  With an older device, the very first measurement in the array will vary in a way that looks random, ranging from 0 to nominal.  With a newer device, the very first measurement should pretty well match all the others, though there may be very small fluctuations due to quantization error.

-Kevin P

[DanFreeze]

Thank you Kevin, I started working on this but the only counter I see in the VI are the counters on the rackDAQ that is also installed on this computer. It looks like I would need an additional module for the cDAQ to access its counter, judging from this article: cDAQ Module Support for Accessing On-board Counters - NI

Do I understand that correctly?

For the counter on the rackDAQ it keeps throwing errors: Error -89130 occurred at DAQmx Start Task.vi:Device not available for routing.

Do you have any suggestions how I could solve this or is this simply a hardware limitation I have to live with?

Cheers

Dan