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
