Acquiring pre-trigger samples

[kgupta]

Hi,

I am using a PCI-6602 board to record the times of incoming pulses. I'd like to add a trigger line so that my program will keep the data of 20us worth of pulses before and after the trigger. I've tried using an armstart trigger, but I've only managed to configure it to start recording pulses after that trigger, and so I don't get the pre-trigger pulses. I've also tried to set up a stop trigger instead: I would read pulse times and discard data older than 20us, and when the trigger comes in I'd let the program run for 20 more microseconds. The problem with that is that, being new to LabView, I haven't figured out how exactly to make this kind of buffer which will discard older data. I looked at a feedback node, configured to only return samples after a number of iterations of my data acquisition loops, but of course that only returns the oldest data. I also feel like using this stop-trigger method seems a bit roundabout. I create a new task for the trigger channel, and I'm worried this may slow down my program because I need to run it continuously (I want data surrounding multiple triggers), and it seems wasteful to recreate the task every time. Any suggestions? Is there a more straightforward way that I have not yet thought of?

Thanks for your help! 

Kamna 

[JÞB]

This is time to set up your task Trigger properties. 

One of the great things about DAQmx is the various levels of access to the Task.  DAQ assistants for basics, the Main palatte for the most common item and Property nodes and advanced palattes to really dig into the guts.  Here is a quick example.  Let me know if there is something I didn't read correctly.

[kgupta]

Thanks for the response!

For some reason I'm having trouble setting the reference trigger properties. When I place a DAQmx Trigger property node on my diagram, I only have two types of properties to set: "Start" and "More", there is no "Reference". I also tried browsing for it, and through I found it in the browser's search menu, I can't place it on my diagram. I feel a little silly about not finding it, but I really don't know where else I could look for it! Is there a certain condition that must be met for it to show up? I'm using LabVIEW 2010.  

Kamna 

[kgupta]

Also, just a quick question on the Control Task VI. You've set the action as "commit" and according to LabView Help this "programs the hardware as much as possible according to the task configuration." ...this seems to imply that LabView doesn't automatically program as much as possible according to how you've configured the task. Could you please explain this a little bit? How *does* LabView configure tasks if it's not according to the information you have provided?  

[JÞB]

Odd,  You should see something like this

using NI-DAQ 9.2.3f1

Is it an old driver?

[Brad_K]

Hi Kamna and Jeff,

DAQmx filters out properties that aren't supported by any of the installed devices. You can change this by right-clicking the property node and choosing Select Filter... then selecting Show All Attributes. The filtering setting gets saved to disk so it's still set the next time you launch LabVIEW. However, this won't solve the original problem, because the NI 6602 doesn't support reference triggers.

By the way, Jeff, using Ref.PretrigSamples also requires setting Ref.TrigType and the corresponding source properties (Ref.DigEdge.Src, etc.). If you set Ref.PretrigSamples in isolation, it will either get ignored (on devices that support reference triggers) or generate an error (on devices that don't). If trigger attributes didn't get ignored when the trigger type is None, then disabling the trigger (by setting Ref.TrigType=None) would require resetting the other trigger properties (via Change To >> Default Value), which would be pretty annoying.

Kamna, as for your question about "commit": a DAQmx task doesn't program the hardware until the task is committed. Starting the task implicitly commits the task, so you don't normally have to worry about it. There is a more detailed explanation in the NI-DAQmx Help file--search for "Task State Model".

Brad

[JÞB]

Thanks Brad!

I didn't have hardware to do more than "show" the trigger property node as a means of setting up the trigger- I appreciate the correction and explaination.

Kamna-

Sean N wrote a scholarly piece on DAQmx Task State flow linked here.  Most often you don't need to get to this level of detail (Warning: do not try this without DAQmx Help OPEN and Wrap your head with duct tape).  Because of Sean's great analisys it appears to be best practice to explicitly commit tasks read or written in loops as it changes the overhead of the Read/ Write call and the state the task is left in after it is "done".

[kgupta]

Thanks for explanations of task-states. I definitely feel like I understand LabView tasks much better now. 

However, I'm still not completely satisfied about my initial problem on acquiring pre-trigger samples. I'm currently using the Collector Express VI to get my pre- and post- trigger samples. That has worked if I set my trigger to come in every 10 seconds (.1 Hz) and when my pulses are at .1s intervals (10Hz). But when I crank up my pulses to more than ~200 Hz (with the trigger still at .1Hz) I start noticing a lag and I get incorrect times. I'm thinking that my data acquisition loop is running too slowly, and the samples that trickle from the buffer to my Collector are old values. If this is the problem, what are some ways to avoid it (perhaps I can configure the DAQmx buffer differently?) ? or is something else happening?

I have attached my code. 

[kgupta]

I should explain: I know I've said that I want data 20us before and 20us after the trigger, and my program right now just takes a number of samples before and after the trigger regardless of when those samples came in. Eventually I may try to change this, but it's not too important right now. Just wanted to let you know I am aware of that; it's not an accident 🙂

[JÞB · Accepted solution]

Those express vi's are notorious for being ineffecient.  All that work just to save the latest 20 values.  Hmmmm OK I attached a mod of your vi that operates like a rolling buffer and operates on the data without type conversion and in-place (should be orders of magnitude faster)  I also initiallized the SR and FBN and fixed a little logic on the counter