daqmx how to tell when pretrigger is complete

[BretRidgel42]

I have some code that is generically written to create a task and prepare it to trigger on an input signal.  The user passes in various options.  This all works great.  Recently I have a case where the user wants to capture a rather long period of time; something on the order of 30 to 80 seconds worth.  I typically go for about a 10% pretrigger.  This is one of the modifiable option they can set, but assuming that's what they want then this will cause a rather long period of time before the device is ready to receive the trigger event.  For instance, 80sec would result in about 8 seconds of pretrigger.  So they would then need to wait that long before starting the test sequence and that sends the trigger signal.  Currently we are hard coding a long wait in their test sequence to make this work and that works fine but is not optimal.  First off they have to remember to do that.  Secondly they have to make sure they wait long enough so they typically would wait like 10 seconds just to be safe.  Is there no way for me to query the trigger state and determine when it is done pre-triggering?  I know on an oscilloscope(DPO4054 series) this status is shown on the screen.  It goes from "pretrig" to "trig?" to "trig'd" for instance.  Seems like the trigger system on DAQmx is very illusive.  I do not see anything in the property nodes that indicate anything about what it is up to.

[Kevin_Price]

Agreed that the ability to query for triggering state would be very useful.  FWIW, you can add a kudo to the suggestion on the Data Acq Idea Exchange.   (Note: Having spent a little time considering it, I doubt NI simply overlooked this property. I suspect it had been considered and rejected for some technical implementation reason long before the linked posting.   Still, it doesn't hurt to add a kudo, you never know...)

-Kevin P

[RavensFan]

I don't understand the terminology you are trying to use here.  A pre-trigger is never "complete".  A pre-trigger setting represents the amount of data to be captured in a waveform before the trigger occurs.  I don't know exactly how NI implements it, but it could be a circular buffer of the pre-trigger time that begins as soon as the task starts.

Once the trigger occurs, only then is the pre-trigger complete and the task will start appending new data to the collected values in the pre-trigger buffer to complete the waveform.

Saying you want 10% pre-trigger requirement is rather arbitrary.    How much pre-trigger is needed should be defined by the signal you are interested in measuring.  If they don't want to wait 8 seconds before starting their task, then they should define a smaller pre-trigger.  Pre-triggers are used to define how much data leading into a meaningful event (the "trigger") you also want to capture.  So if you are looking for a value that exceeds a certain threshold level, then perhaps you want to see a few seconds of the waveform priort to that event.  It should not be considered some forced arbitrary wait.

[BretRidgel42]

Your statement is not really accurate.  If I specify a certain length capture and 10% pretrigger and that results in say 5 seconds of pre-trigger then when I initiate the start of the task, it will not be ready to receive the trigger for 5 seconds.  If your trigger does come before the 5 seconds it will be ignored and nothing will be captured.  That is the issue.  Same as with an oscilloscope.  Now your trigger can come anytime after the pretrigger time has elapsed as it is using a circular buffer.  Best I can tell so far there is no way to determine if this pre-trigger time has elapsed or if a trigger event has happened.  Both of these events would seem like something I should be able to query for so I can avoid waiting excessive times just to ensure they have been satisfied.

[RavensFan]

How much pre-trigger do you need?

Set it for that amount of time rather than "10%".

You don't need to know when the pre-trigger time has passed by querying the device.  You can get a timestamp at the moment you start the task.  Then if you later get another timestamp, you'll know how many seconds have passed since the task was first started.

[Kevin_Price]

[Edit: wrote this up a little here, a little there, and more postings arrived after I started.  Apologies in advance for redundancy.]

My experience poking around at Reference Triggering is relatively limited and I'm not near hw to test.  In the absence of a direct property for trigger status, I wonder if one or more of the DAQmx Read properties can be used?  There are properties for "total # samples acquired" and "# available samples" (sent to task buffer, but not yet read).  I wonder if they can help you distinguish whether a trigger has arrived?  

It seems to me that once you call DAQmx Start, you'll normally go through 4 states:

1. unarmed - the task is still in the process of acquiring the specified # pretriggered samples
2. armed (& waiting for trigger) - specified # of pretrigger samples (or more) have been acquired.  The time this takes is simply a function of sample rate and # pretrigger samples.
3. triggered (& acquiring) - the "# available samples" property might (?) help you determine whether the trigger condition is satisfied.  I'm pretty sure that for *Start* triggering, it returns 0 until the trigger happens.  I'm not sure it does the same for Reference triggering, but it seems fairly logical to me that it might.
4. complete - there's a "task done" property that can be queried for Finite tasks

Detecting when you've transitioned into state #3 is the potentially tricky one, especially if those DAQmx Read properties don't make it clear.  But it sounded to me like your test program will generate the trigger signal whenever you tell it to start, so you were more concerned with knowing when you transitioned into state #2.  But that isn't actually hard to know, right?

-Kevin P