LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

producer consumer error 200279

Solved!
Go to solution

Hello,

So I’m about to go crazy and hoping someone can help me here. I’m writing a program that controls a motor and using a producer/consumer method to write the data at 10,000 intervals a second. I’ve read through multiple examples and I don’t see what I’m missing. I’m trying to record 18 different readings from a DAQ 9178, 3 readings for voltage module NI 9205, 1 reading for current module Ni 9203, 2 readings for accelerometer module Ni 9234 and 12 readings for temperature module 9213. Every time I run the program I keep getting the error message 200279 and it states that it’s trying to read samples that no longer exist. It advised me to increase the buffer rate. So I did as it suggested in multiple ways and the error messages keeps showing up. I’ve also shut down the computer, exited and restarted Labview several times and none of this worked. I have included the a picture file below.  Where the problem is, is in the producer loop and the error is shown coming out of the DAQ error indicator. One idea I had but I’m unsure how to approach it is to somehow mean the data coming out of the DAQ to reduce what’s getting to the buffer. If anyone knows how to fix this problem please explain it in detail (I mean talk to me like I’m stupid) cause I’ve been stuck on this problem for almost two weeks now. Thank you in advance to anyone who can help.

 

SteelTiki  

 

total.JPG

 

 

0 Kudos
Message 1 of 8
(3,917 Views)

Ok here is a new pic of what I"m talking about the purple line coming into the producer is the DAQ

 

total2.JPG

0 Kudos
Message 2 of 8
(3,909 Views)

The DAQ error isn't related to your choice of architecture, although your implementation of it might be hurting you.  It's almost impossible to follow what's going on in your diagram because you have wires running in many directions (try to keep data flowing from left to right), there are local variables all over the place (almost definitely not needed), and there's a lot of code that's not in the image or is hidden in another frame of the sequence.  Normally one would not have the event structure as the consumer loop (as you've done), and it's generally not a good idea to have multiple event structure in the same VI (with rare exceptions usually involving user events).  It might not solve your problem but it would be worth taking the time to clean up your diagram.  Eliminate sequence structures and local variables as much as possible, move some code into subVIs, and straighten out your wires.

 

As for the DAQ error: the DAQ board is reading data into a circular buffer, and you're not reading it fast enough, so samples are being overwritten.  The reason you're not reading it fast enough is because you only read a single sample at a time (the DAQmx Read is configured for 1 sample on multiple channels) but you say you're acquiring 10,000 samples/second.  Since your loop won't run 10,000 times per second, you're not reading all the data, which causes the error.  Try configuring the DAQmx Read for multiple samples.

0 Kudos
Message 3 of 8
(3,896 Views)

You don't tell the DAQmx Read how many samples you want, so it reads the default (1024). You didn't post your init code, so I can't compare it to what you did set.

 

But from code, you have a BIG PROBLEM: WAY TOO MANY LOCALS VARIABLES!

Click the link above to understand why this is a potential problem.

 

Please post a picture of the other other frames of your sequence, so we can help you more.

 

Felix

 

0 Kudos
Message 4 of 8
(3,881 Views)

 


@f. Schubert wrote:

You don't tell the DAQmx Read how many samples you want, so it reads the default (1024). You didn't post your init code, so I can't compare it to what you did set.


Worse than that, actually, as I noted.  That code only reads one sample at a time (note the selector on the DAQmx Read is set to "Nchan 1Samp").

 

Message 5 of 8
(3,870 Views)

Thanks nathand, your eyes were sharper than mine examining the picture.

 

As requested by the OP (original poster), a detailed explanation:

Your DAQ is reading data at the rate you specified and writing it into a buffer. You LabVIEW software is fetching this data one-by-one. But the DAQmx is writing the data faster than you fetch it. However big you'll create you buffer, this error will not go away.

 

You can fix this by:

* reduce the samplöing rate of the DAQ device

* changing the software to read n samples at once.

 

This is also depending on the sampling mode if it's finite or continous.

 

Felix

0 Kudos
Message 6 of 8
(3,862 Views)

Felix,

 

Thanks for replying . I changed the DAQ Read to 2D, cleaned up the wiring and got rid of a lot of the local variable and producer consumer loop seem be working right. However as shown in the picture at the top, I need to also write the speed, torque and few other values that are not coming from the DAQ. So I used an index and a build array and ran them to the array to spreadsheet string also shown in the pic at the top. What I noticed is that it slowed down the acquisition. What is the best way of doing this and keeping the same rate? Next question when writing the 2D array information how do I arrange it in the proper columns. I'm familiar on how to do this with 1D information is it the same way?  

0 Kudos
Message 7 of 8
(3,840 Views)
Solution
Accepted by Steeltiki

Hmm, maybe you can post your newer code/picture.

 

2D array: it is completely the same as with 1D array, all functions are polymorphic. The only thing you will need from time to time is the 'Transpose array' function to swap columns/rows.

 

Considering your complete architecture, I think one issue is the event loop in the consumer. Normally, a event structure is in a producer loop quing up user events that are processed asyncronously. Maybe you can shed some more light on what the other cases of the event structure are.

 

Concerning the write to file speed. The producer/consumer is perfect for passing data from the DAQ loop (producer) to a Write-File loop (consumer), so the access to the hard-disc doesn't interfere with the aquisition. If you change it this way, make sure your queue is not running full (flooded by to high sampling rate). If you need a high sampling rate, change your file format to binary or TDMS.

 

Felix

0 Kudos
Message 8 of 8
(3,824 Views)