Visit our LabVIEW Wiki Hardware Portal
Tags |
(This content has not been tagged yet)
|
![]() |
Mar 4 2004, 07:49 AM
Post
#1
|
|||
![]() Very Active Member Posts: 124 Joined: 17-January 03 From: Southern California Member No.: 37 Using LabVIEW Since:1988 LV:8.0.1 ,. ,.
|
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 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.
|
||
|
|
|||
| Ad |
Mar 4 2004, 07:49 AM
Post
#
|
||
|
|
|
||
|
|
|||
Mar 5 2004, 05:00 AM
Post
#2
|
|||
![]() Very Active Member Posts: 124 Joined: 17-January 03 From: Southern California Member No.: 37 Using LabVIEW Since:1988 LV:8.0.1 ,. ,.
|
Cudos to NI - a very nice product.
|
||
|
|
|||
Mar 5 2004, 05:02 AM
Post
#3
|
|||
![]() Confucius say: Crowded elevator always smell different to midget Admin ![]() Posts: 2367 Joined: 13-October 02 From: Planet Earth Member No.: 2 Using LabVIEW Since:1994 LV:8.5 ,8.2.1 ,7.1.1
My Blog
My Gallery
|
QUOTE (JackHamilton @ Mar 5 2004, 12:00 AM) In your original post you said your local NI rep claimed it wouldn't perform. What changed? --------------------
|
||
|
|
|||
Mar 5 2004, 04:59 PM
Post
#4
|
|||
|
Changing the world, one VI at a time. JKI ![]() Posts: 1696 Joined: 22-October 02 From: San Francisco, CA Member No.: 17 Using LabVIEW Since:1995 LV:8.2.1 ,8.5 ,7.1.1
My Blog
My Gallery
|
QUOTE (Michael Aivaliotis @ Mar 4 2004, 09:02 PM) 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 -Jim This post has been edited by Jim Kring: Mar 5 2004, 05:04 PM --------------------
|
||
|
|
|||
Apr 6 2004, 05:26 AM
Post
#5
|
|||
![]() Very Active Member Posts: 124 Joined: 17-January 03 From: Southern California Member No.: 37 Using LabVIEW Since:1988 LV:8.0.1 ,. ,.
|
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.
|
||
|
|
|||
Apr 16 2004, 09:54 PM
Post
#6
|
|||
![]() Very Active Member Posts: 124 Joined: 17-January 03 From: Southern California Member No.: 37 Using LabVIEW Since:1988 LV:8.0.1 ,. ,.
|
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".
|
||
|
|
|||
![]() ![]() |
| Time is now: 1st December 2008 - 07:31 PM |