setting frame/buffer

[meggy92]

Hello everyone,

I am working with a complex LV program, in which data-acquisition is done using DMA buffers (because data rate is high, 2.2GB/s. DAQ is done using subVIs that came with the DAQboard (AlazarTech)), and some of the data is copied to LV into a lossy queue, on which some processing had to be done and finally displaying. (also some AO signal are created and send out using NI board, but let's forget about that for now.)
The problem I am having is that when I do some processing and displaying buffer overflow of the DMA buffers starts occuring. Buffer size according to Alazar is in the referred range 1-8MB, but at the moment my buffer are 23MB and I cannot reduce them in order to display a certain amount of records per frame. 
Therefore I would like to reduce the size of my buffers (and the numbers of records/frame), and associate at each frame a certain amount of buffers. 

To come to my question, which might not be the correct question to ask, maybe from my story you can guide me in a different direction:

Right now each frame is equal to one buffer, is it possible to associate to each frame a certain amount of buffers?

I hope someone can give me something new to look at.
Thank you very much in advance!
Best Regards,

[pauldavey]

Perhaps you are not reading data fast enough (retrieving it from the buffer). It is hard to comment further without seeing code, but you should have a loop devoted purely to reading the data and passing it off to a different loop for processing (it could be via your lossy queue).

[meggy92]

Dear Paul, thank you very much for replying.

I attached two screenshots in which the part of block diagram related with the buffer management is shown. Actually I already have a loop devoted purely to reading the data and passing it off to a different loop for processing. My problem at the moment is related with reducing the buffers dimension that according to Salazar is too big anyway. That is why I was wondering if it was possible to make that a single frame that I show is made by the data contained in more than one buffer.

best regards,

Margherita

[Bob_Schor]

I took a peek at the pictures of part of your Block Diagrams.  It is difficult to see much, but enough to point out some serious problems:

• You appear to be using the Sequence Structure as a means of setting the serial order of your functions.  This suggests that you do not understand the central LabVIEW concept of Data Flow, which (probably) makes most of these large, blocky structures unnecessary.
• Almost all of the LabVIEW functions, and certainly all of the functions supplied by AlazarTech, have Error In and Error Out terminals on the lower outer connectors.  They are meant to be used!  Among other things, they provide a much nicer and neater "ordering" of function than do Sequences.
• Try to keep your wires horizontal and straight.
• Learn to encapsulate functions in sub-VIs.  Having a large LabVIEW program in a single large VI is the sign of Bad (LabVIEW) Programming, and will result in code that is hard to write, hard to read, hard to debug, and hard to modify.

Now to your question.  Sometimes it helps when special purpose hardware is involved to either attach a manual for the hardware or give us enough information that we can go look for such a manual.  I don't understand what the DMA board is doing, and what is meant by a "buffer".

Can you tell us something about the data you are acquiring?  How many channels are being acquired?  How are the data coming in?  You mention 2.2GB/s (I assume this is Giga-Bytes, not Giga-bits), but are you acquiring new samples every second, every millisecond, or what?  For example, you might acquire a million 16-bit samples at a time "continuously" (meaning the next acquisition starts the moment the first one finishes), so new data arrays come in at the rate of 1100 "million-sample buffers per second".

It sounds to me as though your Alazar board is providing you with a FIFO (First-in, first-out) hardware buffer to get the data safely and securely into computer Memory without needing to worry about whether or not the running Software was "ready for data".  In the above scenario, where new data arrives on the order of every millisecond (a fairly long time for the CPU to do things), what you want to do is get the data out of those "hardware" buffers and into some (expandable) "software" buffers so they can be processed (this is a common trick in LabVIEW RealTime Programming).  As you have figured out, the appropriate Software Buffer is a Queue, but not a lossy Queue (why bother to collect data if you set it up to "lose" it, unless you are doing something like "I want to average the last 5 values").  A FIFO is also a Queue, but one managed, typically, by hardware.  Here's what makes sense to me (but you should test it):

• Accept the recommendation for a smaller Buffer Size.  I'd say you want to be able to hold 3-5 "chunks" of data.  I'm assuming that the data coming into the buffer is "quantized" into, say, million-point "chunks" (a Chunk is a highly technical term meaning "a BS-defined amount of data").
• Create a Queue whose elements are an array of "Chunk" data (i.e. the element type is whatever the Acquisition Hardware provides, i.e. I16, Dbl, U32, whatever, and the array size is the number of these data elements in a buffer).  Do not put a size on the Queue -- you shouldn't need to do this.
• In your DAQ loop, have a loop that reads from the Buffer (I presume it will "block" if there are no new data in the Buffer) and as data become available, puts the Chunk on the Chunk Queue, where it is exported out of the DAQ Loop and into the Processing Loop.
• In the Processing Loop, process the data as quickly as you can.  You'd like to get all of the data processed in (on average) less time than the DAQ loop fills the Chunk Queue.

So now consider the DAQ Loop.  It does almost no processing other than emptying the Buffer as fast as it fills up (so the Buffer can be relatively small) and putting it into an (elastic, expandable) Queue for export.  This should take a few microseconds, at most.

The Processing Loop needs to process the Chunk, and do it in a time comparable, but hopefully on average shorter, than the time another Chunk is put on the Queue.  For Displays, this means do not display every point -- decimate (a lot!) or block-average (a very cheap, in terms of time and code, and very fast Low Pass Filter).

I hope this is helpful.

Bob Schor

[meggy92]

Dear Bob,

thanks a lot for your detailed reply.

First of all, you are absolutely right the software is confused and not well written, it has been written by several users and I started working on it without any previous experience, so I am struggling a lot to understand it.

The software is meant to acquire and display data from an OCT system through the DAQ board (ATS9360 from Alazar).

DMA acquisition allows a board to acquire to on board memory (direct memory access) while at the same time it transfers data from on-board memory to DMA buffers. The DMA buffer is the unit of data transfer between the acquisition board and the computer's host memory. An acquisition consists in the digitalization of one or more records. Each DMA used to transfer data to host memory can contain one or more record. The record length is limited by the max size of DMA buffers in this mode. In my set-up the acquisition rate of the records is performed at 200kHz.

Alazar ATS9360 has 8-line PCIe bus interface which are capable to transfer data up to 3.5GB/s. Data are transferred over the PCIe bus into the DMA buffers, which are located on the RAM. The data can be copied from the DMA buffers to the Labview buffers for displaying.

Labview is in charge of two tasks:

- sending commands for transferring data into the DMA buffers (through ATS Api)

- copy data from DMA buffers to labview buffers. Data can be released from DMA buffers only after they have been copied on labview buffers.

It is correct that my Alazar board is providing me with FIFO. At the moment my data are put in a lossy queue and after that they are processed and displayed (attached I put a screenshot of that part of the block diagram). What I am trying to do now is "build" every frame which I displayed with 4 buffers (each containing a certain amount of consecutive records) so that I can use smaller buffers for displaying instead of using a big buffer to make one frame.

thanks again for replying, I hope my description will be helpful in better understanding my software.

best regards,

Margherita

[Bob_Schor]

Margherita,

I think your problem just got much simpler.  Let me see if I have this straight:

• You are acquiring data at 200kHz.  You don't say how many channels, nor the number of bits of data, but let's say, for the sake of argument, that you are continuously sampling 2 Channels using a 16-bit A/D converter, and are converting 1000 points at a time that are being put into a "Buffer" (I'm still not 100% certain I know how these work, but presume you have software that can manage the Buffers).
• Every 5 milliseconds, 1000 points * 2 channels * 2 data bytes = 4000kB comes into a DMA buffer.  Note that I'm calling this chunk of data a "Chunk".  I assume you have a function that you can put in a While Loop that says "Retrieve the oldest Chunk", and has the property that it will wait, if necessary, for a Chunk to become available, which will be <0.005" if the system is running.
• Inside the loop, you extract the Chunk from the Buffer and put it on a Chunk Queue that you previously created, passing the data to a parallel While Loop that processes the data for you.

That's basically it!  There are, of course, some details like how to start and stop the process, obtaining and releasing the Queue (I recommend using a Sentinel -- if you don't know what this is, don't worry about it, see if the rest of this makes sense first).

Bob Schor

[meggy92]

Dear Bob,

I am acquiring at 200kHz, I have 2 channels, 2000 records/frame, each record is made by 2944 samples:

2 channels x 2data bytes x 2944 samples x 2000 records/samples = 23552000B per buffer.

My problem is currently that this size is too big, as according to Alazar the idea size for the buffer should be between 1-8MB. Indeed as you said I have a function that "Retrieve the oldest Chunk", and has the property that it will wait, if necessary, for a Chunk to become available. Since I want to reduce the buffer size what I was thinking is using more smaller buffers to build one frame.

Thank you again for replying, your input are very useful to me!

best regards,

Margherita