LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

continuous triggered data collection

Solved!
Go to solution

This has to be a solved problem, but despite hours of reading I've been missing it.  I want to start recording an analog signal when a digital line goes high, sample a number of points then wait for the next trigger pulse and repeat.  I can get this to work if I set up my task to collect a finite number of samples, and then run it in a start, collect and stop loop, but there has to be a way to do this that doesn't require stopping and starting the task each time.  I want to start the task, have it wait for each trigger pulse and return the data after the trigger.  If I set it up for continuous collection instead of finite samples, it will wait for the first trigger signal and then collect everything after that first pulse.  Attached are files of two loops.  One where I start and stop the task each time and one where I try to start it once and stop it once.  I doubt the problem is with the loops, but how the task is configured.

0 Kudos
Message 1 of 9
(4,013 Views)

You have to configure the trigger (that is me waving my hands).

 

I suggest you browse through the posts by Kevin Price since he a master at configuring DAQ task to share clock trigger etc.

 

Take care,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 9
(3,994 Views)

Check out this link

 

mcduff

Message 3 of 9
(3,987 Views)

@mcduff wrote:

Check out this link

 

mcduff


Thank you mcduff !

I may not know everything but I do know who does!

 

Spoiler
An old peer of mine told me "Ben you are an encyclopedia!" I said no at best I am an index and can tell you were to look.

 

 

Smiley Wink

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 9
(3,981 Views)
Solution
Accepted by topic author Jim12345678

Take a peep at this article as well:

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019MXxSAM&l=en-US

 

If you're using an X series device, it's just a property node you can set. If not, you will need to set it up with some retriggerable timer tasks.

Message 5 of 9
(3,945 Views)

If you have an X-series device (or other hardware that supports retriggered AI), it'll be simplest to first try what @BertMcMahan said: set the DAQmx Trigger property node for "retriggerable" to True.

 

The thread linked by @mcduff shows a more complicated method I whipped up that's supported on a wider variety of boards.  That approach was kinda necessary in the linked thread, not sure if it's needed for your app.  I would focus my concerns on the thing I mentioned earlier in that linked thread (msg #2 over there).  Can you retrieve all your data from the acquisition buffer before the next trigger signal arrives?   (Or if not, can you live with missing out on that next trigger?)

 

I'd first try for direct re-triggerable AI if your device and app allow for it.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 6 of 9
(3,937 Views)

Thank you for pointing out the x series.  That lead me to investigate the DAQ I was using and determine that it couldn't accommodate the retrigerrable property. I found an x series DAQ in my lab and the code was working in minutes.

Message 7 of 9
(3,858 Views)

As a follow up.....  The continuous retriggerable data collection is working fine for post trigger collection, but from what I've read it appears pre trigger can only handle one event (setting the retriggerable property to true generates an error).  Am I missing something again?

0 Kudos
Message 8 of 9
(3,800 Views)

No, I think that's just a constraint that a task can only be retriggerable if it uses a Start Trigger and does post-triggered acquisition.  Can't say that with 100% certainty, but am pretty sure and don't recall ever reading otherwise.

 

There are some workarounds possible.  Here's a simple one if you don't have super-tight timing constraints on the exact # of pre-triggered samples or a need to know which specific sample corresponds to the trigger event.

- configure your AI task for Continuous sampling

- set the DAQmx Read property 'Overwrite Mode' = "Overwrite Unread Samples"

- also set the property 'RelativeTo' == "Most Recent Sample", and 'Offset' == (-1)*(desired # pre-trigger samples).  You may want to pad that # a bit to compensate for a little additional software response time.

- make another task that will quickly "notice* the trigger signal.  This could be a simple DI polling loop, but there are other methods that could work too.

- when the trigger is noticed, call DAQmx Read on your AI task and request the sum of your (# pre-trigger samples) + (# post-trigger samples).

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 9
(3,778 Views)