trouble trying to acquire data at the full sampling rate using a DAQCard 6024E

[ISS Allan]

I am trying to create a VI that will continuously acquire data and display it on screen. In doing so however, I am unable to acquire data at the max sampling rate of the card (a DAQCard 6024E).

I am running Labview v6.0.2 and NI-Daq v6.9.1 on Windows Me 4.90.3000. The computer is a Dell Inspirion 8000 laptop with a Pentium III processor and 128MB RAM.

I have based my VI largely on the Cont Acq&Chart (buffered).vi example but found that even this example is not capable of acquiring data at the max possible sampling rate.

I have tried many things, including displaying individual channels in their own charts, but to no success. Errors 10845 or 10846 always result. I have searched t
he NI Developer Zone for answers, but have not found anything helpful other than the suggestion to lower the sampling rate.

What we need is to be able to sample multiple channels (at least 4 set up as DIFF channels) simultaneously at a high sampling rate to gain the detail that we need. In a sense the main task of the VI is to act as a Chart recorder, but we want to eventually add analysis options later.

The other VI that I am trying to create is one that will stream acquired data to disc. This is to allow us to perform post analysis through another VI that can read in the data. Would is the best way of achieving this given the problem above.

Many thanks

Allan Angilley
I S Systems Pty Ltd

[Ben]

Hi Allan,

If you provided some numbers, we may be able to nail this issue for you. Without them I will just guess.

The error codes you reported indicate that the app is not keeping up with the incoming data. If you are sampling 4 channels at 50kS/s then the hardware is transfering 200 kS/s into its on board FIFO. Page 344 of the NI catalog indicates that the FIFO can hold 2048 samples before it over-flows. The -10846 error indicates that these over-flows are occuring. To prevent this, the app must completely empty the FIFO more frequently. Doing the math this works out to one empty operation every 10ms maximum.

This is a rather demanding rate. This only addresses the -10846. The -10845 error is troubling. The hardware you are working with may not do the j
ob.

Suggestions:
1) make sure your app is reading at least this often.
2) slow down you Acq rate (I know, not an option)
3) DO NOT TRUST ME! Call NI and talk to their hardware support group and ask them;
a) "Can I do continuous acq from X channels at Y rate using a DAQCard 6024E?"
b)If yes, "Could you point me at an example?"
c)If no, "Can I get credit on this device toward a purchase of a device that can?"



I hope this get you started.

Reply to this answer if you have further inquiries,

Ben

[ISS Allan]

Ben,

Many thanks for the reply. It has been extremely helpful and has cleared up a few issues for us.

Just a couple of questions though:

1) Do we have control over the rate at which the app empties the FIFO buffer of the card?

Until I started investigating the problem I did not realise that the samples were actually stored on the card in the FIFO buffer and then read into the computer. I initial thought that the samples were read directly to a buffer on the computer.

Also, further to the FIFO buffer and PCMCIA operation, I also discovered (through the NI KnowledgeBase document "What is the differene between Data Acquisition Errors -10845 and -10846?") that the PCMCIA bus does not support Direct Memory Access (DMA). Instead, it is apparently
an interupt driven acquisition. The result is that if the system is busy processing other interupts (for say a screen refresh or mouse movement) then the FIFO may be overwritten before the data can be moved. The result is a -10845 overflow error.

Is there anyway around this?

2) When entering the scan rate and the channels into sub vi's such as "AI Continuous Scan.vi", does the sub vi understand that if you enter say 4 channels into the scan list and a scan rate of 200kS/s that this equates to individual channel scan rates of 50kS/s, or does the vi try to scan each channel at the 200kS/s? If the latter is the case, could this be causing problems for us?

Anyway, thanks again for the previous suggestions.

Allan

[Ben]

Hi Allen,

Sorry about the delay in responding.
1) yes and no. Let me ask a more direct question in your behalf, that being "Do we have deterministic control over code execution in the 10 ms range?" Answer:NO. (Search my answers for one of my rants on a related discussions.) It can be done if you are using a Real-Time OS. Now with enough tweaking and poking you could get the app to get the data from the buffer most of the time, but as long as we are not using an RT OS, the "feature" will remain.

2)The value passed to the VI represents the number of samples acquired per second for each of the channels specified in the channels scan list. So,

200,000 X 4 = 800,000 samples placed in FIFO each second.

I hope this helps,

Ben