08-24-2009 06:48 AM - edited 08-24-2009 06:50 AM
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!
08-24-2009 07:43 AM
08-24-2009 07:53 AM
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
08-24-2009 08:03 AM - edited 08-24-2009 08:05 AM
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.
08-24-2009 08:15 AM
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
08-24-2009 08:28 AM
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
08-24-2009 08:29 AM
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
08-25-2009 02:31 AM
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
08-25-2009 02:55 AM
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
08-25-2009 02:59 AM
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!