Buffer size for buffered edge counting

[andros64]

Hi,
If I've understood, using buffered edge counting, the read function should return an array containing the counter's values stored in DAQ's FIFO at each rising edge of the sample clock.
So,I would like to know the buffer size of the 2 counters on M Serie DAQ board.
I would appreciate some help,thanks

[Kevin_Price]

andros64,

In a buffered counting task (or similarly in a buffered analog acquisition task), the buffer being referred to is the software buffer in RAM. You can select this size to be almost arbitrarily large, subject to available RAM. The measurements will be transferred from the DAQ board to RAM using high-speed DMA, which supports very high speed acquisition.

You can specify a buffer size with the DAQmx Timing vi, but DAQmx will actually treat your specification more as a suggested minimum than a definite number. To get the exact size of your choosing you'd use a DAQmx Timing Property Node vi.

Each of the 2 counters can be treated independently in terms of buffer sizes and sampling rates -- the M series boards reserve a DMA channel for each.

-Kevin P.

[andros64]

Dear Kevin Price,
But I thought that there were hardware FIFO on DAQ Board to store analog samples and counters values independently, and with a DAQmx Read vi, the data were transferred from board’s FIFO to PC RAM with DMA channel for each type of inputs.
Reading your answer, I understand that each time a counter value is sampled, this one is transferred to RAM via DMA, and with DAQmx Read vi, I get an array (stored in RAM) containing the counter’s values sampled. Am I right?
If it’s the case, I would like to know:
- If the traffic on the data bus is not too much important because DMA transfer occurs at each rising edge of the sample clock,
- The time to transfer data from board to RAM via DMA.
Thanks again for your help.

[Kevin_Price]

andros64,

You asked:
- If the traffic on the data bus is not too much important because DMA transfer occurs at each rising edge of the sample clock

In practice, this generally will be true unless you start encroaching on PCI bus limits. The PCI bus can theoretically handle up to 133 MB/sec. How much you get in practice is system dependent -- you'll probably lose some efficiency if multiple cards need to share the bandwidth for example.

- The time to transfer data from board to RAM via DMA.

I don't have any precise info. Reports here on ni.com seem to indicate that 10's of MB/sec are possible. Are you concerned about latency from when the sample is taken until the data is available in memory? I'd just comment that the application software calls to access that RAM will take longer to execute than the actual transfer. This is why high-speed buffered acquisitions read many points at a time -- they couldn't keep up reading one point at a time.

-Kevin P.

[andros64]

Kevin Price,
So I don't understand the role of the DAQ's FIFO? And when does the transfer FIFO -> RAM occur?
Thanks again

[reddog]

The size of the FIFO for a counter on an M Series board is effectively two. Once the active edge of your clock occurs, the counter will latch the current count value, transfer it to the FIFO, and request to DMA the sample to the host buffer. As far as latency and throughput rates go, it will be system dependent as Kevin said and will depend on what other activity is occuring on your computer at the time. Typically, I've seen sustained throughput rates around 200 KHz, but again that's system dependent. Latency will be governed by the PCI bus. Arbitration of the bus must be granted to the device before it can DMA the data to host memory. Again, this will be system dependent based on PCI bus activity at the time of the request, but I would expect typical hardware latencies in the microsecond range.

[andros64]

It's ok for me,Thank you very much Kevin and reddog for your help.