Synchronized analog input and output with a long (20,000 sample) output waveform using ni-daqmx base

[Tom_W_[DE]]

Hi John-

Based on your description, it sounds like you are running into an issue where the analog output data is not reaching the AO FIFO quickly enough and is regenerating itself while it 'waits' for fresh data.  My guess is that the apparent sawtooth repetition might actually be the rising edge of your sinusoidal generation.  The fact that the generation concludes with the AO voltage at a value 6k points prior to the end of your write buffer matches the 3x 2k point regeneration that seems to be taking place at the beginning of your generation.

This situation could possible be addressed in a few ways.  First, you could adjust the size of your write operation so that it is more likely to execute quickly and keep up with the AO generation.  Executing quickly implies a smaller write operation, while keeping up implies a larger write operation.  Perhaps a good suggestion would be to write a full FIFO worth of data (8k samples, shared between all AO channels) before starting the generation in order to prime the FIFO with enough data and hopefully keep up with the generation.  This might be helpful, as it appears that up to 6,000 points of generation might be required before your process can establish its timing enough to get all of the data transfers from AI and AO in check and working properly.

Alternatively, you could consider tweaking your sample/update rate to a lower value.  This might not be an option for your application in production, but it would help confirm the throughput issues by allowing the AO to keep up with the generation clock much more easily.  One reason that you might be seeing reduced performance on your PCIe device (relative to Hani's PCI device) is that while neither device supports DMA for AO in DAQmx Base, the PCIe device could operation significantly slower due to the comparably slower programmed-I/O rates associated with PCIe bus operations.

On a side note, the console prints at build time are due to an issue with interoperability between PPC and Intel Mac software that early versions of LabVIEW had difficulty working around.  With help from Apple we (NI) have been able to avoid this issue, so future versions of DAQmx Base will not show these prints at build time.

Hopefully this helps-

TOMW
NI Measurements Software

[john.clements]

Hi Tom,

Thanks for your insightful reply. As you suggest, pre-filling the FIFO does help. Also, slowing the sampling rate from 50 kHz (a typical value for my customers) to 5 kHz eliminated the saw-tooth output problem. I'm embarrassed that I didn't try a slower sample rate sooner (though I have tested with faster sample rates).

So, it seems that you are right - this is a timing issue "where the analog output data is not reaching the AO FIFO quickly enough". I'm amazed that a state-of-the-art PCIe bus on a 2.6 GHz processor can't transfer a block of 1,000 samples every 10 ms, but there you are! Presumably, the problem will be even worse with a USB-2 interface to the M Series card?

Pre-filling the FIFO makes my code digitizer-specific and breaks down at higher sample rates (fortunately, higher than my customers will generally use). Sounds like I might be stuck with this slightly kludgy approach? I couldn't find a way to determine the size of a device's FIFO using DAQmx Base, so have hard-coded the value I determined from trial and error.

I do have another serious (show-stopper) issue with the PCIe-6251 card on an Intel Mac. The output waveform is contaminated with a periodic glitch, and progressively desynchronizes from the analog input. The desynchronization is sample-rate dependent, so may be another timing issue. I have started a separate thread on this issue (titled "Input corrupted by glitches..."), which you can review at...

http://forums.ni.com/ni/board/message?board.id=250&message.id=35218#M35218

John.

[Tom_W_[DE]]

Hi John-

The root of the problem is that DAQmx Base is "bit banging" the AO samples out to the device FIFO via programmed I/O.  This type of process is notoriously slow when a serial bus (such as PCIe) is used. 

On the other hand, you mention USB2 so I assume you're interested in a similar device in USB form factor, perhaps the USB-6251.  I should point out that the USB-622x and USB-625x devices are not planned for addition to DAQmx Base but that support for the bus-powered USB-621x is under development for possible inclusion in a future release of DAQmx Base.  With those devices in DAQmx Base, a mechanism similar to the NI Signal Streaming technology supported by DAQmx will most likely be used for AO transfers.  So it is possible (though not guaranteed) that you might be able to see better performance with the USB-621x devices once they are supported.  However, as you mentioned before, it is a bit of a stretch for you to purchase another M Series device in the hopes that the performance might improve.  We will perform benchmarking when/if it comes time to release that support and I will post back here if the performance is significantly better with the USB-621x device.

To address your other question, I can tell you that the "glitching" issue is something that we (NI R&D) were made aware of by our applications engineering department and that we are actively investigating.  I do not have a good idea of when we can offer a fix, but we will definitely update your other thread with any pertinent developments.

Thanks-

[john.clements]

Hi Tom,

Great insights into the current status of DAQmx Base - thanks. Wish I'd know all this before spending several weeks attempting to add support for NI digitizers to my commercial OS X application, AxoGraph X (axographx.com).

Is it fair to say that, as of today, National Instruments does not offer a practical solution for customers requiring accurate 50 kHz synchronous analog input / output, and who use a modern Intel-based Mac computer for data acquisition?

Or is that only the situation for third party developers relying on NI-DAQmx Base. As I understand it, the OS X version of LabVIEW also relies on NI-DAQmx Base, so it is also affected by the glitch / desynchronization problems?

These are not hypothetical questions - we will be putting this information in a forthcoming newsletter that is going out to our customer base, so would appreciate an answer.

This is potentially disappointing news for our Mac OS X customers (currently ~1,000), many of whom will be looking to purchase new or upgraded digitizer at some point. NI digitizers are very cost-competitive. On the other hand (if I'm correct) it means that LabVIEW is not a viable solution at present, which may enhance the appeal of our product (in combination with a digitizer from another manufacturer) to potential Mac OS X customers.

John.

[Jeremy_C]

Hello John,

I appreciate your feedback regarding NI-DAQmx Base on the Mac.  While we do strive to provide a quality driver that will meet most of our customer's needs, admittedly there are some gaps.  With that said, we may have a couple of options that I would like to discuss with you offline.  If you give me your permission, I can request your contact info from our web admins and contact you directly.  I look forward to speaking with you.

Thanks,

Jeremy Crawley

Measurements RLP Group Manager

National Instruments

[john.clements]

Hi Jeremy,

Happy to discuss this with you offline (I'm based in Sydney, Australia).

I understand that Apple have provided digitizer engineers with a moving target in recent years, which must be frustrating. But OS X is now settled and stable (more so than Vista), as is PCIexpress and USB-2. Intel-based hardware and the Unix core should make life easier for DAQmx Base developers (less byte-swapping for one thing). Hopefully you can help me identify a viable, cost-effective NI digitizer solution for my customers, although it looks very much like an upgrade of DAQmx Base is required first. Look forward to hearing from you.

John.