LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

simulatneous AI and DO using USB6009

Hi,

I'm trying to write a program that will simulatneously stimulate a cell and record two sets of responses using Labview 8 and a USB6009 DAQ card.
The stimulus is a series of rectangular pulses of 20ms duration and frequency between 1.2 and 10 Hz. I'm using DO for stimulation and AI to record the voltage response (sampling at 4Khz).

For testing purposes I'm using a stimulus of 20ms , frequency 10Hz repeated 1000 times. I  have only used one AI channel although another AI channel will have to be added later on.
The rectangular pulse was generated by appling a DO of TRUE, waiting for 20ms and then applying a DO of FALSE. The AI READ function is used to clock the cycle duration (read 400 samples at a rate of 4000Hz = 100ms). A for loop was used to repeat the pulses 1000 times. The output of the DAQ was observed on a scope.

The problem is that I'm not getting an accurate rectangular pulse. There is an +-2 ms variation in the pulse width (a +-10% error) and up to 4ms variation in the interpulse delay (a 5% error) which is quite alot for my experiments.

I have tried using two USB DAQ cards (a 6009 and 6008) one for DO and one for AI but still had the same problem. which suggests this is a software problem.
If I only use DO without aquiring any signal (removed the create AI task completely) and I get a perfect  rectangular pulse with no variations in inter-pulse timings.

I've attached a copy of the VI.
Is there a better way of setting up the AI or looping through the AI read to get rid of the variations?

Thanks for any tips
Amr

Message Edited by Amrosh on 07-27-2007 02:57 AM

0 Kudos
Message 1 of 7
(3,336 Views)

Unfortunately I don't think you can achieve what you wish using the low cost USB-6009.

See this thread where this question was asked before... http://forums.ni.com/ni/board/message?board.id=250&message.id=22880&requireLogin=False

 

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
0 Kudos
Message 2 of 7
(3,326 Views)
Hello Amrosh,

Trey is right and the results you see are expected.
The way you wrote your code is actually doing software calls to change the digital lines. These software calls will be OS dependent and therefore might have large jitter.
Your hardware does not support to do this in hardware so basically that is the trade off.

Gerardo O.
RF SW Engineering R&D
National Instruments
0 Kudos
Message 3 of 7
(3,310 Views)
Thanks Troy and  Gerardo for your quick replies,

I had a suspicion that the USB6009 can't produce the accuracy I wanted..

1) I am still curious why when I use the DO task alone I get no jitter (it could be still there but its definitely less than 1ms)?? The large jitter is only  introduced when I add the AI task. So I though there was something wrong with the way I set up the AI task, AI timing and AI read functions that is slowing down the calls to the digital lines..

2)This is a general question about data flow in labview during simultaneous input and output tasks.  From what I read on the forums about the USB6009 specs, I get that the AI is hardware timed using the onboard clock but DO or AO are software timed.
My question is how does labview switch between DO lines and AI channels. Do the DO and AI tasks operate separately in parallel or does labview switch between them? For example for each rectangular pulse loop in my program, does labview acquire a set of samples, store them onto a hardware buffer,  then call the digital line, repeat this process ,,,,, and once the buffer is full and all the finite samples are collected move them into computer memory ???

cheers
Amr

Message Edited by Amrosh on 07-27-2007 11:17 PM

Message Edited by Amrosh on 07-27-2007 11:22 PM

0 Kudos
Message 4 of 7
(3,304 Views)
As to your first question:

When you have your AI task and your digital task in the loop, you actually have two Wait functions executing that will conflict or add to each other. One of the Wait functions is implicit in the Analog Read function. It has to wait for the next set of data to be acquired and arrive in memory. The second Wait function is your explicit delay function in the Sequence structure with the digital reads.

You should only have one of these wait functions. Having a continuous DAQ task that runs on a sample clock will time your loop for you. I'd imagine you'd get better performance by moving the Analog Read function into the first frame of the Sequence structure with first DO call, before the explicit wait function.

Message Edited by Jarrod S. on 07-29-2007 11:23 PM

Jarrod S.
National Instruments
0 Kudos
Message 5 of 7
(3,268 Views)
Hi Jarrod,

thanks for the tip.
Using a continuous DAQ task only slightly reduced the jitter.
I did some further testing by moving the Read function to the first frame of the sequence and reading a single sample.  It seems that it takes 1ms to move between each iteration of the loop.
Regarding your second tip. I did some testing and couldn't figure out how you would time the loop using the continuous DAQ task. If the analog Read function is placed in the first frame of the sequence, the DAQ task will stop reading when labview moves to excuting the second frame and third frames in the sequence? Could the Read function be made to run in the background as labview moves between the frames of the sequence?

Amr
0 Kudos
Message 6 of 7
(3,236 Views)
Hello Amr,

A loop that has a DAQmx read in it will time itself using the number of samples to read. For example, if you acquire at 4k and you read 400 samples, the VI call will take about 1ms (assuming it was called as soon as the acquisition started). This is why there is no need to do this.

I am not sure how exactly is your timing diagram but here is a revised version of your initial VI. I took the sequence out since you control execution using error clusters (you should use them, they are very helpful). If you run this, you will see that you acquire 100 ms of data and you capture the entire 20 ms pulse. You can then post process the response since you know it should arrive after the pulse.
Gerardo O.
RF SW Engineering R&D
National Instruments
0 Kudos
Message 7 of 7
(3,214 Views)