Retriggerable waveforms with external stop trigger

[dsdale24]

This is my first question to the forum, please bear with me...

I have a PXI crate with three NI PXIe-6341 X-series DAQ cards. I have been searching the forums and Labview's standard examples trying to learn how to do the following, but am struggling a bit. We have a programmable motor controller that will continuously scan a rotation axis and emit a TTL pulse every X degrees to synchronize data acquisition. I need to record samples from several channels simultaneously: quadrature encoders, counters for a couple of external V2Fs, a few simple voltages. I'm trying to use Labview-13.0 to do the following:

1) Start a continuous acquisition that samples the various channels at some frequency (say 100-1000 Hz). The samples should be synchronized, shifts in timing due to multiplexing are not a concern.

2) Receiving the TTL signal from the motion controller causes the series of data from each channel to be saved to memory or file, begins next continuous acquisition

3) Repeat (2) until Y sets of data have been acquired, or the acquisition is interrupted

Could anyone please offer advice? Is there any additional information I can provide?

Thank you,

Darren

[Joel-I]

Hi dsdale24,

Welcome! The NI Shipping examples are a good place to start.  Within LabVIEW go to:

Help» Find Examples...» Hardware Input and Output» DAQmx

The examples found here can help you get started on different components of your overall application.  

You can also search the examples online at ni.com/examples

These are great resources to get you started on the right path.

Good luck!

[dsdale24]

I spent some time looking through the examples before posting my question. Maybe I just don't know what it is I'm looking for. The manual for my device http://www.ni.com/pdf/manuals/370784d.pdf indicates that continuous mode DAQ is not compatible with a digital stop trigger, that acquisition must be stopped in software. On the other hand, I found a brief discussion about using the DAQ board to trigger non-DAQ events (http://forums.ni.com/t5/LabVIEW/Using-DAQ-to-trigger-non-DAQ-event/td-p/2579469), which naively sounds like it might do what I need. I have a TTL out from a function generator (at 10 Hz) wired to pins 52 (P0.0) and 18 (D GND) on a SCB-68A, which I *think* is port 0 line 0, but when I run the attached VI and highlight execution, the event structure is never executed.

Is this a reasonable line of approach, and if so, any ideas why the event structure is not executed?

Thanks

[dsdale24]

Here is a slightly modified example that increments a numeric indicator at every event timeout. I've verified with the Digital I/O test panel in MAX that my PXI1Slot3/port0/line0 is indeed changing state. Can anyone guess why this VI is not yielding change detection events?

[Izzzzz]

Hello dsdale24, 

The VI you posted is not  yielding change detection events because you have not enabled this feature in hardware. To enable this feature you have to utilize the Change Detection Instance of the DAQmx Timing.vi. Please take a look at the snippet below where I modified you code to  enable this event. 

Also from taking a look at your earlier post I wanted to clarify the functionality you need.

2) Receiving the TTL signal from the motion controller causes the series of data from each channel to be saved to memory or file, begins next continuous acquisition

When you receive the TTL signal from the motion controller are you interested in logging the data acquired at the moment (Before and after the trigger), or do you want to store the data from the beginning of the acquisition until the trigger was received? What do you mean by "begins next continuous acquisition"? 

If you are only interested in the data surrounding the trigger then a reference trigger would be useful for your application. This will give you the option of acquiring samples before and after the TTL signal. Although you can only set up to acquire a finite amount of samples and will have to stop and restart the task if you hope to continuously acquire. While stopping and starting the task there is a chance of missing the next TTL pulse if the TTL pulse arrives during the time you are restarting the task. This can be mitigated by reducing the time between the Stop and Start with the DAQmx Control Task.vi in order to commit the task. If you are interested in the latter then a continuous acquisition with a modified version of the change detection code to log the data when the external event is received would be the route I would take. 

Also, since the title of this post is retriggerable waveforms with external stop trigger, please take a look at this example for how to implement a Stop Trigger. In order to make this retriggerable you will have to stop and start the task (after the trigger has been received) which like I mentioned above may cause you to miss the next trigger if the trigger arrives during the restart. 

Regards, 

Izzy O. 

[dsdale24]

Thanks for the comment Izzzzz. The functionality I need is, each time I receive a trigger from the motion controller, I want to log all of the data acquired since the previous trigger from the motion controller. So if I'm receiving triggers from the motion controller at 5 Hz, and sampling each channel at 100 Hz, I should be reading out 20 values at each trigger.

I have a new VI attached that works up to a point. There is a slight difference from what you posted, I found that I needed to include a "start task" on the change detection line to make it work. Regardless of the sample rate, once the VI has recorded up to 1000 points, it stops acquiring new data. It is still responding to external triggers (reported in the "edges" indicator), but the waveform chart is not updated and the array length read at each port0/line0 trigger is 0. Any idea why that might be?

Thanks,

Darren

[Izzzzz · Accepted solution]

I believe the behavior you are seeing can be attributed to the DAQmx Timing.vi Implicit Instance for your Counter Output Pulse Frequency Task. By leaving the Sample Mode input blank you have left it in the default configuration for a Finite Generation which will only generate 1000 pulses. Also good catch on the DAQmx Start Task.vi, in my haste I forgot to include this function. 

Regards, 

Izzy O. 

[dsdale24]

I just figured out why the last VI I posted wasn't acquiring more than 1000 samples (same as Izzzzz's suggestion). I'm configuring a counter output to serve as the sample clock (in this case, PXI1Slot3/ctr1 which I can then use for the sample clock via PXI1Slot3/PFI13), but the timing VI sample mode for ctr1 needed to be configured for continuous samples, but it defaults to finite samples.

I guess I shouldn't have used "retriggering" in the title of this thread. I'm still learning the terminology.

Attached is a version of the VI that appears to be working as intended: samples a counter at a specified rate, reads the samples when a TTL is sensed on port0/line0. Finally, I physically connected the output of PFI13 to the gate of the counter I'm using to count edges, which resets the counter to 0 after each sample.