10-05-2009 10:18 PM
Hi all,
I guess I'm a newbie at all this DAQ programming with NI hardware, so hopefully one of you can answer this question for me. We are attempting to create hardware in the loop type functionality in a system we are building and require the ability to output dynamic digital data at a rate of around 5khz. We are using the RT CVI environment to write much of the code needed to perform our tasks. We were hoping to keep the number of samples written to card down to a minimum of 2 samples. We are allowed to do this by DAQmx API and the PXI-6259 but have discovered there is a couple second latency between sending the samples to the card and when data is outputted from the cards. Now i'm assuming there is a FIFO style buffer on the 6259 that is causing this problem. From my prodding through the DAQmx API, I've been able to retrieve the hardware buffer size of 2047. (is that 0 to 2047?) So my question to you is, can this buffer size be reduced in size to only handle 2 sample sets of data? Rather than try to hammer through all 2k worth? Any suggestions or ideas will be greatly appreciated!
thanks for your time!
10-06-2009 03:44 PM
Hi dahunt,
There are other considerations to review before the buffer size. What form factor is the 6259, i.e. PCI, PXI, USB? Can you elaborate more on your DAQmx programming sequence? Please also provide more information on what data you are outputting and how this is being generated. What is your sampling rate? Is the process contained in a while loop? The additional information should provide a better idea of your program and process.
10-07-2009 08:44 AM
Well lets see....
The NI hardware is 4 PXIe-6259 cards plugged into your 18 slot hybrid chassis and NIRT controlled with your PXIe-8106. (The chassis also has a GeFunuc reflective memory node plugged in as well.) Anyhow, we are using the 4 6259s to generate 4 synchronously clocked 32bit words. Basically, port 0 on each of the boards. These digital signals are then sent our to our custom breakout box to control several external components. The sample clock runs anywhere from 5 kHz to 15 kHz and is derived from the 10Mhz PXI_Clk10 clock using on board counter. Our system will have up to three different PXI chassis and/or computers, and they will be all 10Mhz ref synchronized to the same ref. The data that is sent to the 6259 cards is retreived from the attached reflective memory network. There is another system on the reflective memory network that is dynamically generating these values. These values are updated at the previous mentioned sample rate and 2 samples deep at a time. (i.e. (4 * 32 bit words) * 2 samples deep). So far the host PXIe system has no problem keeping up the transfer of data from the reflective memory network to the 6259 cards. The problem is there is a definite multi-second latency after giving the data to the 6259 card and when the data changes on the card output. This characteristic is amplified at lower sample rates. We've seen this before in other devices with hardware FIFOs. Is there a way to mod the size? Or is the only way to clock the data faster?
Oh ya... I the event handling. I am using DAQmxRegisterEveryNSamplesEvent and telling it to call my callback after every 2 samples. I.e. "DAQmxRegisterEveryNSamplesEvent(pDigOutTask[0],DAQmx_Val_Transferred_From_Buffer, DIGOUTBUFFERDEPTH, 0, PrimeDOBuffer_callback, pCallbackData)" The system is event driven as much as possible.
steps in data gen.:
1. Setup up sample clock ref from PXI_Clk10 at 5 kHz using counter
2. Setup up Gate signal for active high condition... generate data
3. Setup 4 daqmx tasks to generate clocked digital data out
4. Setup up 1 EveryNSamples event based on the first daqmx task
5.When event occurs, data is retrieved from the reflective memory network and sent to the 4 cards via DAQmxWriteDigitalU32
that is the basic loop.
Hope this helps
10-12-2009 04:02 PM
First you can try implementing DAQmxSetBufOutputOnbrdBufSize, which sets the Output>>On Board Buffer Size property. This was found by Start>>Programs>>National Instruments>>NI-DAQ>>Text Based Code Support>>NI-DAQmx C Reference Help.
Depending on how your program is set up, this could be handled automatically. This an excerpt of the DAQmx Help>>How is Buffer Size Determined?
How Is Buffer Size Determined?How Is Buffer Size Determined?
For generations, the amount of data you write before starting a generation determines the size of the buffer. The first call to a Multiple Samples version of the Write function/VI creates a buffer and determines its size.
You also can use the Output Buffer Config function/VI to create an output buffer. If you use this function/VI, you must use it before writing any data.
The samples per channel attribute/property on the Timing function/VI does not determine the buffer size for output. Instead it is the total number of samples to generate. If n is your buffer size, setting samples per channel to 3×n generates the data in the buffer exactly three times. To generate the data exactly once, set samples per channel to n.
NI-DAQmx does not create a buffer when the sample mode on the Timing function/VI is set to hardware-timed single point.
If you are not already using Producer/Consumer architecture and queues to handle your data, then it may be worth looking into.
11-01-2009 08:53 PM
Thanks for the suggestions. But unfortunately there doesn't seem to be a way to get around that 2047 sample deep digital hardware buffer. The api calls don't do anything at all. I even tried driving the card with max sample clock to push the day out faster... but due to the async low data update rate, the output was wayy to jittery. Is there not a way one can write directly to the digital output without using that onboard FIFO? Perhaps some debug configuration register on the card that DAQmx doesn't have access to?
I guess the ideal card for our application should have been the one of the FPGA cards.... but we were looking for a generic card we could keep on the shelf for our other DAQ projects. The M-Series may not fit this application as we had hoped.
Thanks again for your time. Sorry for the late response... Nasty week long meetings 😕
11-03-2009
03:50 PM
- last edited on
05-06-2011
12:56 PM
by
Laura F.
The new X-Series cards support hardware timed single point for digital output which sounds closer to what you may have needed. Page 122 of the X-Series Manual elaborates on this topic. It was released this summer and similar to M-Series is a good, generic DAQ card. Unfortunately M-Series does not support hardware timed single point on digital output or counters. Beyond that an R series card or FlexRIO might be another option.