Error -200361 occured at DAQmx Read

[ltvedt]

We have a problem with "Error -200361 occured at DAQmx Read" when sampling at 500kS/s using the 9201 in a USB-9162 carrier. It

seems that our program is acquiring the data quicker than it is able to process it. We have an oscillating circuitry, oscillating at about

190kHz. A coil is placed around a glass tube with ferroelectric powder passing, and we want to monitor the change of this resonance

frequency due to the amount of this powder in the coil using a Labview program. The frequency is then used to calculate the flow of

powder and the approximate mean flow during a minute.

The program is made in LabView 8.6, and saved as a 8.0 version for use in a computer with Win XP SP2,

3GHz, 1GB RAM and LabView v8.0.

The program works fine using the computer which it was made in, but when it is beeing run in the computer to be used, error 200361

occurs immediatly. I created a button to turn on/off plotting the results in graphs, as this seemed to take a lot of resources, which helped

a bit. I also changed the priority for LabView to "High" in task manager, and now it works for some time, before it crashes.

It also seems to crash when starting an other LabView program which also has to run on the computer.

I have attached the vi and sub-vi, could someone please take a look on it and give advice on how to make the program more efficient?

Thanks!

Message Edited by ltvedt on 08-24-2009 01:50 PM

[StefanA]

What NI-DAQmx are you using on your computers?

[Davidek]

Hi ltvedt

I had a quick look at your application and one improvement I can suggest is to use a Producer/Consumer design pattern. With this you use two loops, one to acquire the data and another to process it and a queue to communicate between them. You can find a template if you open File->New and then under VI->From Template->Frameworks->Design Patters->Producer/Consumer (Data).

Best Regards

David

NISW

[ltvedt]

Thanks for your quick reply!

I am not shure which version it is, but I think it is 8.0.1.

I am not currently on site with this computer, so I cannot check it.

My office computer where it works fine has 8.7.2 installed.

Also an update regarding the error message, it is Error 200279, not 200361 as stated earlier.

I tried the method of producer/consumer, and found that the buffer just increased in size,

which made me realize that the problem was that the data was processed slower than the

aquisition of new data.

Message Edited by ltvedt on 08-24-2009 03:05 PM

[StefanA]

Do you still get your error or is it fixed by increasing your buffer size?

If not please have a look at this KB Entry.

Stefan

[ltvedt]

The error will not appear when using producer/consumer, but the buffer will continue to grow quite quickly. This will also give a lag

in the returned flow of the powder.

I will check the KB entry and see if I can figure it out tomorrow.

Thanks a lot for your help so far!

Lars

[Davidek]

Hi 

Those two error codes have can alternate and are both a sympthoms of the same problem. You are reading data into your application from the buffer slower than you are reading data from the instrument to the buffer.

One solution to this is to attempt to disconnect the reading from the processing (the pattern I talked about in my last post) which in essance is a way of buffering in you application. Another is to read the data at a slower rate. Yet another is to read larger chunks (more samples) per iteration.

Best Regards

David

[ltvedt]

Hi,

We cannot reduce the sampling speed due to the speed of the powder and the need of "seeing" the grains as they pass the 2cm long coil. I changed the program to include a producer/consumer structure. I also increased the "samples per channel" in the Sample Clock as well as the amount of samples to be read by the DAQ. The samples per channel was set to a integer multiply of 1024 and the amount of samples to be read was set to half of this buffer size.

As I understand it, by using an integer multiply of 1024, the FFT of the signal will be done much quicker.

Now the program seems to run fine as long as no graphs are plotted.

Thanks for all help!

Lars

[Davidek]

Hi Lars

That's great!

Just remember that if this is an application that is supposed to run for a long time a good test to run is to visualize the number of samples in the buffer (see the KB linked earlier by Stefan) and number of elements in the producer/consumer queue (get Queue status.vi). This to make sure thay are stable and not just increasing more slowly. If they are increasing slowly you have just prolonged the problem. That may be enough depending on how fast they increase and your application. Just something to keep in mind, hope everything continues working well

Best Regards

David

[ltvedt]

Thanks for the heads up David,

I added an indicator on the # of elements in the queue, to be able to check this. The system will be running throughout the day to check if it is stable.

I will post as soon as I am shure everything is ok.

Again, thanks a lot for all the help guys!