LabVIEW
is this possible in labview 8.2 and the usb daq 6009?
The problem with the DAQ assistant is that it does a lot all inside of it. It creates the task, runs it, then closes it. That's fine for a one time acquisition, or one that isn't too fast. But the creating and closing of the task takes time and won't allow it to run very fast in a loop. So it is best to use the lower level DAQmx functions so that you create the task before the loop, acquire the data inside the loop, and close the task after the loop and program is over. You may want to look at the producer/consumer architecture so that you can pass the data acquired out of the loop using queues and allow a parallel while loop do the data processing and display.
What is the sensor you are using. If it passes through the sensors in 2 ms, it sounds like you would only have about 2 samples at 1 kHz where the object is present. You may need a higher sampling rate. I guess it all depends on what kind of data you are acquiring and what it means to you. It looks like the USB-6009 can handle up to 48 kS/sec. So theoretically you could acquire at a rate of up to 12 kS/sec on each of 4 channels.
It sounds like you are on the right path, so keep experimenting with the setup and working on it.
Perhaps you can explain your project in a little more detail and tell us what you are trying to accomplish. It looks like you are using 4 phototransistors to count seeds? The seeds pass by 1 at time? Are there 4 phototransistors to capture a wider area?
If you are counting seeds, why are you worried about the max, min, and std deviation of a voltage? Why the noise vs. seed boolean switch? The case structure as a data2 array indicator in the true case, but a value property node that is only rad in the false case. What is the point behind that?
In your program, you have several controls where you don't use the terminal (+ and - of gain 0 thru 3). You use the value property node to read it, but why did you rename the value property nodes to + or - limit 0 thru 3? This is very confusing and not a good programming practice. You really should not use value property nodes if you can avoid it. They are slow and can lead to race conditions. Local variables are faster, but could still lead to race conditions. You should use the terminals of controls and indicators, and use shift registers to maintain the values between loop iterations.
PS. The color choices for your front panel are rather harsh. It is difficult to read black text on a dark background.
Message Edited by Ravens Fan on 02-23-2008 04:42 PM
