Buffer problem

[Thijs Boeree]

I have to aquire my data (multiple channels) in data records of 1000
samples (EDF format 1000Hz sample-rate), therefore i must set the
"number of scans to read" in the "AI read.vi" at 1000. This causes my
while-loop to slowdown at a rate of 1 second per loop, then when a want
to display the achieved data the refresh rate is also 1 frame/s. Is
there any possibillity to achieve data in bloks of 1000 samples(: ch1
1000 samples....ch2 1000 samples.... etc.). But that I can see my
achieved data with a frame rate of 50 frames/s, working with multiple
while loops doesn't work the acquisition loop slow it down?!

Anybody?

Best Regards,
Thijs Boeree

[markwysong]

Absolutely. I have done this many, many times.

Let's understand what is happening first. If you are just using a loop
that sets up a continuous acquisition, and reads 1000 points every
iteration, when the AI Read is called, you stop the data acquisition
"thread". If any other data acquisition VI is called, it won't execute
until this AI read is finished, or 1 second has elapsed (because of your
1000 Hz sampling rate), even if it is in another loop.

Therefore, to eliminate this problem, take a look at the Labview example
under examples\daq\anlogin\anlogin.llb\Cont Acq&Chart (Async
Occurrence). This vi uses the DAQ Occurrence VI which allows Labview to
generate an occurrence (like an interrupt) when the buffer contains a
certain amount of data (say, 1000 scans!), and you can hold off doing
your AI Read of 1000 scans until the buffer contains that much data.

What does this do for you? It doesn't tie up the data acquisition
thread anymore. In a separate loop, now you can perform another AI
read, but this time you're going to read 1 scan, and you're going to
read it referenced to the END of the buffer. This will get the last
scan that went into the buffer (the most recent data), and that is what
you can display on your graph. This will NOT interfere with your
buffered acquisition.

The only trick is that when you make the call to read the 1000 scans in
your other AI Read, you must make that referenced to the "beginning of
buffer", because your other AI read will move the buffer marker, which
is the default read location of the AI Read.

Give that a try. I know it works. Let me know if you have any trouble.

Mark

In article <39F9481D.E19030B0@amc.uva.nl>,
Thijs Boeree wrote:
> I have to aquire my data (multiple channels) in data records of 1000
> samples (EDF format 1000Hz sample-rate), therefore i must set the
> "number of scans to read" in the "AI read.vi" at 1000. This causes my
> while-loop to slowdown at a rate of 1 second per loop, then when a
want
> to display the achieved data the refresh rate is also 1 frame/s. Is
> there any possibillity to achieve data in bloks of 1000 samples(: ch1
> 1000 samples....ch2 1000 samples.... etc.). But that I can see my
> achieved data with a frame rate of 50 frames/s, working with multiple
> while loops doesn't work the acquisition loop slow it down?!
>
> Anybody?
>
> Best Regards,
> Thijs Boeree
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

[Thijs Boeree]

First of thank you for the fast response!!

I opened the example "Cont Acq&Chart (Async Occurence)" and already made
another while loop, putted the AI read in it, but now I don't know what you
mean by "you're going to read it referenced to the END of the buffer." How
do I wire this? I not that familier with LabView yet, can you send me a
simple VI where the seperate loop is displayed, i don't need the Cont
Acq&Chart because i already have 'm.

What do you do with LabView?

Best regards, Thijs Boeree

mark.wysong@ae.ge.com schreef:

> Absolutely. I have done this many, many times.
>
> Let's understand what is happening first. If you are just using a loop
> that sets up a continuous acquisition, and reads 1000 points every
> iteration, when the AI Read is called, you stop the data acquisition
> "thread". If any other data acquisition VI is called, it won't execute
> until this AI read is finished, or 1 second has elapsed (because of your
> 1000 Hz sampling rate), even if it is in another loop.
>
> Therefore, to eliminate this problem, take a look at the Labview example
> under examples\daq\anlogin\anlogin.llb\Cont Acq&Chart (Async
> Occurrence). This vi uses the DAQ Occurrence VI which allows Labview to
> generate an occurrence (like an interrupt) when the buffer contains a
> certain amount of data (say, 1000 scans!), and you can hold off doing
> your AI Read of 1000 scans until the buffer contains that much data.
>
> What does this do for you? It doesn't tie up the data acquisition
> thread anymore. In a separate loop, now you can perform another AI
> read, but this time you're going to read 1 scan, and you're going to
> read it referenced to the END of the buffer. This will get the last
> scan that went into the buffer (the most recent data), and that is what
> you can display on your graph. This will NOT interfere with your
> buffered acquisition.
>
> The only trick is that when you make the call to read the 1000 scans in
> your other AI Read, you must make that referenced to the "beginning of
> buffer", because your other AI read will move the buffer marker, which
> is the default read location of the AI Read.
>
> Give that a try. I know it works. Let me know if you have any trouble.
>
> Mark
>

[markwysong]

On the AI Read VI, there is an input which is a cluster that contains
the position and read offset where the read from buffer should occur.
You can set the position to the "End of the buffer", and the read offset
to zero. This would retrieve the most current piece of data entered
into the buffer.

If the position were "relative to the beginning of the buffer" and then
the read offset was the iteration of your loop times the number of scans
to be read per loop, this would read x scans in the correct position of
the buffer for your DAQ occurrence loop.

Mark

In article <39FD396D.CDE41D66@amc.uva.nl>,
Thijs Boeree wrote:
> First of thank you for the fast response!!
>
> I opened the example "Cont Acq&Chart (Async Occurence)" and already
made
> another while loop, putted the AI read in it, but now I don't know
what you
> mean by "you're going to read it referenced to the END of the buffer."
How
> do I wire this? I not that familier with LabView yet, can you send me
a
> simple VI where the seperate loop is displayed, i don't need the Cont
> Acq&Chart because i already have 'm.
>
> What do you do with LabView?
>
> Best regards, Thijs Boeree
>
> mark.wysong@ae.ge.com schreef:
>
> > Absolutely. I have done this many, many times.
> >
> > Let's understand what is happening first. If you are just using a
loop
> > that sets up a continuous acquisition, and reads 1000 points every
> > iteration, when the AI Read is called, you stop the data acquisition
> > "thread". If any other data acquisition VI is called, it won't
execute
> > until this AI read is finished, or 1 second has elapsed (because of
your
> > 1000 Hz sampling rate), even if it is in another loop.
> >
> > Therefore, to eliminate this problem, take a look at the Labview
example
> > under examples\daq\anlogin\anlogin.llb\Cont Acq&Chart (Async
> > Occurrence). This vi uses the DAQ Occurrence VI which allows
Labview to
> > generate an occurrence (like an interrupt) when the buffer contains
a
> > certain amount of data (say, 1000 scans!), and you can hold off
doing
> > your AI Read of 1000 scans until the buffer contains that much data.
> >
> > What does this do for you? It doesn't tie up the data acquisition
> > thread anymore. In a separate loop, now you can perform another AI
> > read, but this time you're going to read 1 scan, and you're going to
> > read it referenced to the END of the buffer. This will get the last
> > scan that went into the buffer (the most recent data), and that is
what
> > you can display on your graph. This will NOT interfere with your
> > buffered acquisition.
> >
> > The only trick is that when you make the call to read the 1000 scans
in
> > your other AI Read, you must make that referenced to the "beginning
of
> > buffer", because your other AI read will move the buffer marker,
which
> > is the default read location of the AI Read.
> >
> > Give that a try. I know it works. Let me know if you have any
trouble.
> >
> > Mark
> >
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

[Roger Isaksson]

Mark,

I'm trying to do the same with DAQmx on an RT PXI system.

I have a timed loop with 500ms loop time for 1000Hz Counters and Analog Buffered reads. The control loop has a 20ms loop time. Is it possible to read from the buffer, using DAQmx Read in these two loops, without altering the current read position?

Is there a way to configure the DAQmx task(s) simiar to the example with the"DAQ Occurrence VI"?

Regards

Roger Isaksson, Damill AB

[Roger Isaksson]

If I am correct, the code in the threads below should achieve this?

DAQmx: http://forums.ni.com/ni/board/message?board.id=280&message.id=1272
Traditional DAQ: http://forums.ni.com/ni/board/message?board.id=170&message.id=139740

Regards

Roger Isaksson, Damill AB

Message Edited by Roger Isaksson on 09-07-2005 04:25 AM

[JustinTheAlias]

How do I get an example like the one your talking about if I hav daqmx? I have been trying to do just this but cant find an example.

Thank you,

Justin

[G_Lo]

Justin,

From the previous post, there is a piece of code at this forum which should do the job.

[rlg50]

I have a similar problem. I've inherited some labview 7.0 software for a data acquisition system. The system uses two pxi 6052e daq cards and currently uses 3 channels on each card and the software works great; however, when I converted it to use 4 channels per card, there is an error code -10846 regarding buffer offerflow, size, timing, etc. I've tried everything imaginable to get this fixed and it's not working. There is an RTI capture vi which sets the buffer size for each card and it is set at 10000 (I've changed it to lower and higher values and with larger values the problem occurs less frequently). I've also changed the wait time divide by number in the case seen in the attached photo (I am still unsure of the purpose of dividing here so if someone could explain that would be awesome). I've also changed the number 1920 to higher and lower values (Again, I'm not sure of the purpose of this value, but I do know that it controls the size of the output matrix from this sequence). The error only occurs on the top buffer read sequence. Any and all help is greatly appreciated. Thank you very much.