Dynamic Waveform Output

[JackHamilton]

I've had a project come to a grinding halt - mainly over a glossed over requirement - that is quite odd.

We need a DAQ card to output a stimulus signal (waveform) of varying types, and not just classical sine and square waves - but a constructed waveform loaded into memory.

:!: Now the catch... we need to output a continious signal which is used to 'stimulate' a sample unit under test. When a special spike signal is output to the test device - it 'responds' to the stimulus - we need to then output a different waveform pattern - to make the device believe the test device has effected the signal.

The problem is we need to

1. Output a continuous waveform pattern - then via a software trigger

2. Change the output to another pattern. All within a few msec.

What were finding is that S & E Series DAQ cards were never intended for this scenario; why? I'll tell you. Thinking we'd be clever we are using both analogs outs and routing them to a signal input. So we can play one waveform and preload another when the response is required.

A. You can't configure one waveform output to be software triggered and the other hardware triggered. DAQ Error results. This is true with Traditional DAQ & DAQmx.

B. The latency in the actual waveform output from a software trigger is atrocious! Were seeing 100msec ~ 250msec latency with a 100% variance in response. S-Series DAQ card on a P4 2.0gig processor. LabVIEW 7, DAQ 7.1. Hardware triggereing is superbe - but again- if your already playing a waveform on one channel - which we are - you can't configure the other for hardware triggering.

The card reaction time is so long and variable, we can't even measure the performance of the test device, we need reliability of better than 4msec and want 1msec. This is really odd that a MegSample card performs so poorly.

The card we're using 6120 has 32meg of waveform memory - but you can't load several waveforms in that memory and then play a 'segment' of that memory out - a la memory pointers. Were only looking at 5Khz output sample rates.

We are now taking a look at the arbitrary waveform cards PCI-5411, but the NI rep is telling us it won't perfom either! They are recommeding the FGPA, but it's got very little memory (1 meg) to store waveforms. Real-time was another suggestion - but again your using the same hardware.

It appears to be a driver issue, it's just not intended or optomized for this scenario. Using 2 DAQ cards will stilll have the problem - because the driver is using common memory buffers in the OS.

We've tried double-buffering, but it's CPU intensive and believe me the system has many other things to do. We've got about 18 threads running in this code.

Anyone have any other hardware suggestions? We've looked at some Agilent Waveform generators but they take about 30 seconds just to load 1.k of waveform data via GPIB - this is too long for us.

[JackHamilton]

:thumbup: Thanks to a great demo from our local NI rep. The Arbitrary Waveform generation card PCI-5411 & 5421 series will do the trick. You can load up 2 million samples in the card and using 'scripting' select which segment of the memory to output. Even has markers which will output a TTL pulse for a specific sample.

Cudos to NI - a very nice product.

[Michael Aivaliotis]

:thumbup: Thanks to a great demo from our local NI rep.

In your original post you said your local NI rep claimed it wouldn't perform. What changed?

[Jim Kring]

In your original post you said your local NI rep claimed it wouldn't perform. What changed?

NI is really pushing the FPGA product, which is probably why they told Jack that he needed it without fully evaluating other options.

Until I read to Jack's second posting, I was going to recommend calling NI again to get a second opinion about the ARB. They are designed for exactly the task he described In fact, you can also set them up to respond to hardware triggers for *very* fast response times.

-Jim

[JackHamilton]

Jim,

The 5411 Arb card has one very strange caveat that does NOT exist with the E or S Series cards.

The response time to a hardware trigger is 78 clock cycles - which is clocked by the sample waveform output clock! so outputting at 3 Khz will have a 25msec latency in response!

We are outputing at 3Khz with a hardware trigger targeted for a 100msec delay - but we actually get 125msec???

This is nowhere stated in the spec (who'd want to!) Also the triggering is pretty unsophisticated - you can only trigger one sequence. So the marketing lit about "Stimulation and Response" is pretty limited.

My wish list would be better drivers for fast output pointers on the waveform buffer, we need to do some real-time stimulation and response - and need to determine what exact waveform to transition to on-the-fly. The drivers are not optimized for this. But the card does take only about 43msec to stop, reconfig and output another waveform in memory.

[JackHamilton]

In the end the Arb card did not work for us either. As we needed to analyze 4 channels of analog feedback data to determine what response to playback - we could not in software call the arb card within 60msec of the event.

Although a simple model of using a DAQ occurance to flag a notification to change the arb card works. We needed to also pass to the arb card which sequence to play based on software analysis of input analog data. We could not get those two events to occur fast enough to arm the arb card before the timed hardware trigger fired.

I don't see this in any way as a failing of NI hardware. Trigger/Response applications with on-the-fly data processing should really should be done in hardware.

I was able to lay hands on a 7041 Real-Time card - which did work, including acquistion, analysis and output response. with only about 200usec of dither over repeated tests.

I guess I would take exception to the arb card marketing literature which states it's "ideal for stimulus /response applcations".