Continuous acquisition not keeping up

[CAS]

I am writing my first NIDAQmx application after previously using Traditional NIDAQ. I've just started with some basic test code to try and read a number of analogue inputs continuously from 2 devices. My system details are:

LabVIEW:  8.2.1

NIDAQmX: 8.5.0f5

OS: WIndows 2000

Devices: SIMULATED PCI-6250 (2 off)

Channels to acquire: AI0 to AI10 on each device, simultaneously.

Sample rate: 80kHz

My application configures the acquisition by creating 2 tasks, one per device, configures the channels then the timing (set to continuous, 'samples per channel' varied, see below). I then start the task then call DAQmx Read for each task in a loop. I'll attach the code.

I've tried varying parameters like buffer size and number of points to read but cannot get a configuration that doesn't end up with the error message that data in the buffer has been overwritten because I haven't retrieved it quick enough. I can just about get the code going if I use the default buffer size (which is 100k I believe for my 80kHz) and then set the number of points to read to 160k. This is not ideal as I had hoped to update values to screen more often than every 2s.

Could the problem be that the simulated device isn't simulating accurately? Have I missed some set up? I have put some diagnostics in to check how many points have been acquired and how many are available to read at various points in my code but don't understand the results. I've had this report that the number of points acquired doesn't change over a 2s period. I've also seen the number of points acquired increase but the number of points available to read be 0.

I'd appreciate your top tips as I'm sure that LabVIEW/DAQmx must be able to cope with this relatively low spec acquisition problem. The loop that I'm doing my reads in isn't even doing any other work yet - I have lots of other acquisition, calculations and displays to add.

CAS

[KostasB]

Hi Cas

I've attached a VI that acquires from 2x 6251's simulated devices at 80kHz per channel  (AI0 to 10 on each device). It runs fine on my computer

without giving me any errors. It updates the screen every 0.5 seconds. Does it work on your computer?

Regards,

KostasB

NI Applications Engineer

[CAS]

Dear Kostas,

I get the same problem with your VI. After 3 loops, I get the error message: 'Error -200279 occurred at DAQmx Read (Analog 1D Wfm NChan NSamp).vi:21'. Perhaps there's something in the configuration of the devices? To run your software I simply added two simulated PCI-6251s in MAX and kept the default settings. (Incidentally, I did try it with my original simulated 6250s first and had a similar result).

Some straw-grasping: I've only got 512MB RAM - though I would've thought that that was sufficient?

Thanks for your effort - any further suggestions would be welcome.

Cheryl

[KostasB]

Hi Cheryl

512 RAM should be OK with LabVIEW 8.20. If you set the Samples to Read to '-1' does it solve the problem? If you set Samples to Read to '-1', the program

will read all the available samples from the buffer. In this case, you may get uneven chunks of samples but you will be reading them as fast as possible..

Regards,

KostasB

NI Applications Engineering

[CAS]

Dear Kostas,

I have tried reading all samples at once by setting the 'Samples to Read' to -1. This starts off okay but then crashes with the same error. Does my VI work correctly on your machine? On my PC, if I set 'Samples to Read' to -1 I produce the debug info:

Task 1 Channel 0

(Times are in s from the start of the VI and the 'Points available for transfer' and 'Total points acquired' are obtained from the DAQmx Read Property Node. I check these values before and after transfer, i.e. calling DAQmX Read.)

Time before        Points available     Total points        Total transferred     Time after             Points available     Total points              

acquisition         for transfer             acquired                                        transfer                 for transfer             acquired

in s from start    before transfer        before transfer                                in s from start       after transfer          after transfer

0.19                  10854                    10854               10854                    0.45                     15375                   26229

0.55                  15375                    26229               26229                    0.61                      0                         26229

0.92                  0                           26229               26229                    0.95                      0                         26229

0.95                  0                           26229               26229                    0.95                      0                         51652

1.50                  25423                    51652               51652                    1.58                       0                        51652

1.86                  0                           51652               51652                    1.89                       0                        51652

2.83                  0                           156175             51652                    2.86                       0                       156175

Similarly for Task 2 Channel 0.

As you can see, although new samples have been acquired between loops (as indicated by the 'total points acquired' increasing), the number of points available for transfer is set to 0. Is this the problem? And if so why is this occurring? And why does so much time pass without the number of points acquired increasing? Am I interpreting the use of the property node correctly? I am assuming that it gives me the current state of the input buffer.

If you can get my software to report the error on your PC then you will see this debug information appear on the screen. (N.B. I normally set the 'Task 1 Buffer Size' = 'Task 2 Buffer Size' = 0 to use the default buffer.)

Any ideas?

Cheryl

[Kevin_Price]

---

Could the problem be that the simulated device isn't simulating accurately? ...

---

I haven't done a ton of stuff with simulated devices, but I don't think they are intended to mimic the timing behavior of a data acq task.  Not unless that's been a specific enhancement in recent versions of DAQmx.

-Kevin P.

[Quantumbyte]

Cheryl,

The irregular timing problems you're seeing definitely have to do with the fact that the devices are simulated. Simulated devices will return data immediately whenever you request it, regardless of the rate you specified.

Of particular interest to me is the fact that you're setting your Buffer size to 0, which is not the default. In order to choose the default you should not be setting your Buffer size at all. Non-buffered operations won't be able to keep up with the data produced by a simulated device, giving you the error you are seeing.

As for the property node, the Total samples per channel acquired simply indicate how many samples per channel have been transferred to your PC buffer, on the other hand AvailSampPerChan tells you how many of those you haven't read yet. If your computer is fast enough you could go through several iterations of your loop without being able to read anything.

Thanks

Daniel D.

Multifunction DAQ

Message Edited by Quantumbyte on 11-05-2007 05:02 PM

[CAS]

Thanks for your comments, Daniel & Kevin. I am relieved to learn that the problems are only due to the behaviour of the simulated device.

Daniel, when I set the buffer size to '0' in the top level VI, I leave the 'Samples Per Channel' input of the DAQmX Timing VI unwired in my lower level VI. I was assuming that this would use the default buffer size - is this assumption correct? I have carried out my tests with the buffer size set explicitly to 100k and higher and have seen similar results. I can get an increase in the reported points acquired value while the points available value is set to 0. I can also get a sudden increase in the number of points acquired which is disproportionate to the elapsed time. Given that I am setting the buffer size correctly, would you still expect this behaviour from a simulated device?

Although this unpredictable behaviour of the simulated device makes my feasibility testing more difficult, as long as the actual hardware will behave correctly with the configuration I have used, then I've no need to worry.

Thanks.

Cheryl

[KostasB]

Hi Cheryl

If you set explicitly the buffer size to '0' it means that you want to perform non buffered acquisition. If you don't set the buffer size at all then it will use the default value DAQmx decides.

If you want to set the buffer to your specified size, you need to use the DAQmx Configure Input Buffer vi. Note that the 'Samples per Channel' input of the DAQmx timing VI is not

the buffer size.

You can also call us in our office at 01635572400 and quote your service request number  if you would like to discuss about it.

Regards,

Kostas

NI Appilcations Engineering