topic Re: Acquiring pre-trigger samples in LabVIEW

Acquiring pre-trigger samples

kgupta — Tue, 02 Aug 2011 19:51:16 GMT

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

Re: Acquiring pre-trigger samples

JÞB — Tue, 02 Aug 2011 20:53:21 GMT

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.

Re: Acquiring pre-trigger samples

kgupta — Tue, 02 Aug 2011 21:31:45 GMT

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

Re: Acquiring pre-trigger samples

kgupta — Tue, 02 Aug 2011 21:37:21 GMT

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?

Re: Acquiring pre-trigger samples

JÞB — Tue, 02 Aug 2011 21:53:31 GMT

Odd, You should see something like this

using NI-DAQ 9.2.3f1

Is it an old driver?

Re: Acquiring pre-trigger samples

Brad_K — Tue, 02 Aug 2011 23:50:51 GMT

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

Re: Acquiring pre-trigger samples

JÞB — Wed, 03 Aug 2011 15:04:41 GMT

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".

Re: Acquiring pre-trigger samples

kgupta — Wed, 03 Aug 2011 18:34:07 GMT

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.

Re: Acquiring pre-trigger samples

kgupta — Wed, 03 Aug 2011 18:44:46 GMT

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 🙂

Re: Acquiring pre-trigger samples

JÞB — Wed, 03 Aug 2011 20:49:22 GMT

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

Re: Acquiring pre-trigger samples

kgupta — Fri, 05 Aug 2011 17:06:03 GMT

Thanks Jeff for that code! I did need to tweek the In Place Element Structure because it turns out that when you program it to split the 20-array into subarrays of length 1 and 19 and then try to insert a value into the 19-array, it inserts it at the same place you make the cut (in this case in the first spot) rather than just appending the new value to the end of the 19-array. However, I used a similar idea using just "Delete from Array" and "Build Array" to accomplish the same thing. Anyway, the code is working much faster now (I think fast enough! Hurray!)

Thanks again for your help!

-Kamna

Re: Acquiring pre-trigger samples

kgupta — Mon, 15 Aug 2011 16:31:58 GMT

Hi,

I have another question. I am now trying to expand my program to include 2 counters (eventually it will have 6), still triggered by the same line. I tried adding the second counter to the same while loop, but that slows the program waayyy down and I eventually get a buffer overflow error, probably because my loop is no longer running fast enough to read the values from the buffer. Is there a way around this? Or should I place my data acquisition tasks in separate but synchronized loops and somehow try to link my trigger loop to my counter loops?

Re: Acquiring pre-trigger samples

kgupta — Mon, 15 Aug 2011 21:31:45 GMT

Actually, I kind of resolved the speed issue (rather than putting everything in one large while loop I split it up, I'll stick with that unless there's a better way that I haven't thought of?) Now I have a question on synchronizing the while loops. I have the timing set up so that whenever there is a pulse on my data line, my program reads the the counter value on the 20MHz Timebase. If I set up several lines this way, would they automatically be synchronized because they all use the same 20MHz Timebase?

Thanks in advance for your help!

Kamna

Re: Acquiring pre-trigger samples

Andy-K — Tue, 16 Aug 2011 16:40:15 GMT

Hi kgupta,

If you would like all the counters to have the same setup and synchronize to the same clock, you can include them all in the same DAQmx task. You can do this by selecting all of the counter lines you are iterested in acquiring at the start of the DAQmx task. Then the read will output a value for each counter.

When using multiple DAQmx tasks running in parrallel, the best way to insure they are acquiring at the same time is to set the clock source to the timebase you would like then trigger one task with the other. There are some great examples on this included in the Labview example finder under synchronization in the DAQmx folder under Hardware Input and Output. I hope this helps!

Re: Acquiring pre-trigger samples

kgupta — Tue, 16 Aug 2011 18:28:55 GMT

Hi Andy,

Thanks for the reply!

Unfortunately, I don't think I can do that directly in my case. The aim of my code is to get the times of a line data pulses. I do this by running my 20MHz Timebase and I have the computer return the counter value of that timebase whenever a pulse arrives. To do this, I treat my pulse as the clock because the arrival of the pulse is what controls when I take the value from the 20MHz counter. I realize this is a little roundabout but it works and I could not think of a better way that would also give me the microsecond precision I need. In order to expand this to several incoming pulses, I need to use one 20MHz timebase as the counter, but several clocks (one clock for each stream of pulses), and I want separate data for each pulse line. Is there a way to do this, using one task?

I don't have hopes for there being a way to do this in one task, in which case I go back to my original question: if every task uses the 20MHz Timebase, will they all be synchronized, since there is only one timebase on my card?

Kamna

Re: Acquiring pre-trigger samples

JÞB — Tue, 16 Aug 2011 19:22:41 GMT

@kgupta wrote:

I don't have hopes for there being a way to do this in one task, in which case I go back to my original question: if every task uses the 20MHz Timebase, will they all be synchronized, since there is only one timebase on my card?

Kamna

YES, and you can even route an external source to use as your timebase to syncronize several cards together. PXI expands this a bit futher by routing the clock source with correct delays so that the clocks arrive at the same time (Time on target)

Re: Acquiring pre-trigger samples

kgupta — Tue, 16 Aug 2011 20:08:50 GMT

Great! That makes my job easier 🙂

Follow-up: how can I correct for the time delay? I have the PCI-6602 card.

Re: Acquiring pre-trigger samples

JÞB — Tue, 16 Aug 2011 21:19:45 GMT

@kgupta wrote:

Great! That makes my job easier 🙂

Follow-up: how can I correct for the time delay? I have the PCI-6602 card.

Throw out the PCI card and buy a PXI device and a backplane (Chassis) and controller that supports time on target sync.

You need better hardware that supports the advancesd clock sync features