LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Getting latest samples from a running task

Hi all,

I've been struggling with the following for several days now, but cannot find a satisfactory solution so far.

I need to run an AI-task (nothing critical regarding speed, lets say c.a. 1kHz sample rate), that continuously reads channels on an AI card (I am using a 9201 in cDAQ 9188, but have tried an USB daq as well and the problems are just the same). Then, at some random times I need to get the last n samples from the buffer, while the acquisition continues. As this operation should be executed from different threads, it is possible that I execute overlapping readouts as well.

I need all this to be able to get the data quickly, from different areas of my program, but still enable some integration over the samples.

I am using the DAQmx read properties of "Relative to" (last sample) and "Offset" (-n), followed by a standard DAQmx read analog VI, but what I am getting is samples which are too old, values that remain unchanged for multiple readouts or just errors, depending how I configure the timing of the task.

It is just a simple requirement - read last n values from a continuous task, but I cannot make it work.

Thank you in advance for your suggestions!

Cheers,

mirode

PS. LV 2012, DAQmx 9.6.1f1

0 Kudos
Message 1 of 7
(2,566 Views)

I would recommend having a separate thread to handle all of the reading from the DAQmx channel.  Have it read the data and save it in a circular buffer.  I would actually recommend using a Functional Global Variable (aka LV2 Globals, Action Engines).  Your other threads can read this data from the FGV whenever they need the data.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 7
(2,563 Views)

Hi crossrulz,

thanks for your fast response. In fact I was thinking of such a solution, but cannot believe there is no way to utilize the DAQmx buffer which is just there...

0 Kudos
Message 3 of 7
(2,559 Views)

Mucking with the DAQmx buffer and reading it from multiple threads scares me.  I can easily see why you could get stale data.  Besides, you really should only have 1 place reading from hardware.  It makes things a lot cleaner and scalable.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 4 of 7
(2,555 Views)

I understand your point, but still I AM using 1 point buffer access, with a single sub-VI which is not reentrant.

Anyway I begin to like your idea with the circullar buffer.

0 Kudos
Message 5 of 7
(2,549 Views)

Another solution would be to post your latest data to a notifer. Your read task can post the data to the notifer and the readers will always get the most recent data from when the process the notification.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 6 of 7
(2,540 Views)

Thanks guys, I am trying out both methods to see which one best integrates with the rest of my software and the tests so far are very promising.

 

0 Kudos
Message 7 of 7
(2,513 Views)