DAQmx continuous acquisition problem

[Melissa Niesen]

I am (finally) changing my DAQ VIs from Traditional to DAQmx and I'm having problems.  I am trying to replace code that formerly used "AI Continuous Scan.vi" which worked great.  I have attached a simplified version of my attempt at recreating my use of this VI using DAQmx.  The problem is that is seems that data is made available to my DAQmx read function only in multiples of 256 scans.  Am I missing a setting somewhere that lets me get data as fast as my loop runs? 

I've also attached a simple representation of how I used Traditional DAQ to solve my problem.

I am using LabVIEW 8.0.1 with a DAQCard-6036E.

Thanks for any help!!

Melissa

[devchander]

Could u post the Pic of the block diagram of those VI's??

Also refer Examples shipped with LabVIEW, find examples>>Hardware input output>>DAQmx>>Analog measurements>>Voltage

Here, open any relevant DAQmx Measure voltage vi and try to understand how Continous acquisition is done in DAQmx ( refer to its documentation too)

[Melissa Niesen]

Here are the BD pics.

I did look at several of the examples included with LabVIEW.  None seem to be exactly what I want, but some are close.  I don't see what is different with my attempt that would make it behave so oddly.

Another weird thing... One example that is close to what I want is the Cont Acq&Graph Voltage-Int Clk.vi .  When I run this, the FP indicators and my probes only update once every 51 times through the loop.  I've never seen something like this. Is my LabVIEW installation haunted?

Message Edited by Melissa Niesen on 07-19-2006 09:17 AM

[chrisger]

Hi there

i just ran the vi you posted and the example "Cont Acq&Graph Voltage-Int Clk.vi". both work as expected. i get the data continously and without any gaps.

"When I run this, the FP indicators and my probes only update once every 51 times through the loop." please place a breakpoint on the graphs wire to check if the problem is the loop execution or the data.  

my setup:
LabVIEW 8.0 PDS
DAQmx 8.1.0f1
Simulated NI-PCI6036E

i'd suggest to repeat your tests with a simulated NI-PCI6036E card (go to MAX and right click on DAQmx devices, then create simulated device) and do some tests with your real 6036 card in MAX testpanels (mark device in the tree and then select "Testpanel"). if you still have problems i'd do a clean re-install of LV WITHOUT traditional DAQ support.

[Melissa Niesen]

Thanks for the replies.

If I use a simulated device both VIs (mine and the example) run fine, too.  The test panel also seems to work fine with my actual board.  I'm not surprised, though.  If I run "Cont Acq&Graph Voltage-Int Clk-Timed Loop.vi" with my actual card, it also looks fine, however when I use property nodes to see what is going on, I'm also seeing this 256 sample data chunk buffer.  In that example, it waits until 256 samples are there and then starts reading them down as more chunks of 256 scans are added at a time.  I see this by looking at the scans available.  With my settings (scan rate=100, read 10 scans at a time) this means that all of my data is delayed by 2.56 seconds, which is not acceptable for my application.

I also don't see why the weird display update rate problem with "Cont Acq&Graph Voltage-Int Clk.vi" would be depend on whether a simulated or actual device were being used.

I'll first try updating DAQmx.  I'm using 8.0.0f0 right now.  I'm leary of spending hours reinstalling LV when I still need Traditional DAQ anyway.  But I'll probably end up there in the end.

Melissa

Message Edited by Melissa Niesen on 07-19-2006 11:12 AM

[Melissa Niesen]

I did upgrad to DAXmx 8.1, but the actual problem was something else. 

See http://forums.ni.com/ni/board/message?board.id=250&message.id=23091

The problem was the board had it's "Data Transfer Request Condition" set to "Onboard memory more than half full" rather than "Onboard memory not empty" like I needed it.  I'm not sure why this would be the default setting.  Also, I'm still not sure why that would cause the display problem I was seeing with some VIs, though.