sustained data throughput on PCI-6143

[Scrx]

Hi all,

Can a PCI-6143 card maintain a 30,000 Simultaneous Samples Per Second rate for 120 seconds? (at 16 bits, for three channels)

3.6 million samples, 21.6 million bytes total.

So far, it seems it cannot, using:

LabView 7.1
Core Duo processor at 2.2 GHz
0.5GB RAM
WinXP

Nothing else running (besides the usual XP rot. No antivirus (it doesn't even have a network connection...)).

Is it the card or LabView that's the problem?  

Scrx

[S_Hong]

Hi Scrx,

Considering that you are acquiring approximately 180 Kb/sec (30ksamples/sec*3 channels*2bytes/samples), this should not be a problem for you PCI-6143. What version of DAQmx are you using? Could you describe to me what error message you are getting when running your code? Have you tried running one of our shipping examples? The one I would like you to try running is the Acq&Graph Voltage-Int Clk.vi in your Example Finder under Hardware Input and Output » DAQmx » Analog Generation.

Perhaps you can include a snapshot of your DAQmx task so we can have a better look at the problem.

[Scrx]

Whoops - How'd I get an empty post there?

Anyhow, first, thank you for responding, S_Hong, and you'll find more about this project in the LabView forum, under 'My system gets weird at loop count ~2050'

http://sine.ni.com/niforum/niforum?requireLogin=False&forumDU=http://forums.ni.com/ni/board/message?board.id=170&message.id=367959

 Please note that it all sorta worked - Up until Loop Count 2050, when the internal counter timing went haywire - Observe the screenshot in the first post.  

 Apparently, then, it is LabView that's the problem - Or at least, the 'Express' routines being woefully inefficient.

 I will try your examples and see if I can get what I want.

  Thanks,

  Scrx

[Scrx]

PS - DAQmx version is 8.6   S.

[S_Hong]

Hi Scrx,

From taking a look at the forum post as well as your code, it seems that the source of the problem may be because you are running a software timed (sample on demand) counter task. This means that the counter tasks are going to be completely dependent on your software execution. Since this means that your tasks are no longer deterministic, you may be acquiring your counter measurements at different times. It is possible that for later iterations, you may be handling a larger data set which then causes a delay in your counter task offseting all your data.

I hope this makes sense.

P.S. In the future, if possible, we would like you to keep the same issue on a single thread as this will help other customers and application engineers to find all the necessary resources they need when tackling similar problems.