how to set the number of elements dequeued?

[masu]

Hello All,

I am relatively new to LabView. I use LabView 8.2 to detect Joystick movement using a set voltage threshold. Totally, I have 6 channels of analog input. The sampling rate is 2 Kilo Hertz with continuous sampling mode (buffer size set to 10 Kilo Samples). I show a visual stimulus on a computer monitor. Within  3 seconds from stimulus onset, the subject has to press the joystick. So I use a while loop that runs until the subject moves the joystick in any direction as detected by crossing of voltage threshold. The while loop was intended to run for a max of 3 sec if joystick was not moved. My intention while using the vi (see below) was to continuously monitor the voltage signal by means of removing voltage data points from the queue by the labview function/vi - "dequeue element". When I dequeue from inside the loop, the dequeue function removes about 100 msec worth of voltage data points ( = 198-201 points; sampling rate -2Khz) from each of the six channels. This creates problem for me because a single dequeue operation takes 40 to 85 msec during which the loop cannot be stopped. This results in miscalculation of the actual time when the joystick was moved.

Is there a way to set how many data points the dequeue function removes? My goal is to remove about 1-2 msec worth of data points so that the loop can exit within under 5msec of the joystick movement.

I have attached the screen shots of the subvi's I am using.

Acquire Response.jpg - the while loop that has the subvi: Access Analog Data Queue

Access Analog Data Queue.jpg - front panel of the subvi that has the 'dequeue element' function.

Remove Element.jpg - a case of Access Analog Data Queue.vi showing the 'dequeue element' function

Sorry for the long message. Any help would be greatly appreciated.

Thanks

Mani

[johnsold]

Mani,

Dequeue always removes exactly one element from the queue each time it is called.

It is hard to be sure from the images you posted, because the enqueuing is not explicitly shown. It appears that you are enqueuing a waveform so the amount of data in that waveform is what will be dequeued. To get the fine grained results you want, you may need to enqueue in smaller "chunks" of 1 ms.

Perhaps you should consider a circular buffer. You could read and write at different amounts so long as the average rates were such that buffer overflow does not occur during your experiment.

Lynn

[tst]

Or use the Flush Queue primitive which will return all the elements in a single call.

[masu]

Hello Lynn and tst,

Thanks for your suggestions. I have attached a screen shot of a vi that has the enqueue function. As Lynn pointed out, it was the enqueueing size that was reflected in the size of the dequeueing. I tried various ways to control the enqueue element size in order to control the dequeue element size. Many of my tricks failed. I had set the data acquisition to be continuous at 2kHz with 10Ks buffer size. You may want to look at the attached image of the subvi "Analog Acquisition" while I explain my attempts. The first thing that I noticed was the 'dt' value in the input node of the timed loop which had been set by somebody to 100. I thought that was part of the reason why my dequeue size was always worth 100msec data points. So I changed it to 1 msec. This definitely made a difference in the chunk size of the dequeued element. Now dequeueing removes only data points worth 1 - 5msec. I also noticed that my data reading timer loop(the while loop in "Analog Acquisition" picture) takes about 20 -25 msec instead of the set 1 msec.

Why does the loop take so long? I have set the 'number of samples per channel' to -1 so that DAQmx read.vi (see it in Analog Acquisition subvi block diagram) can grab whatever data is available currently and put that into the queue. Can this be a reason why the loop takes more than 20 msec? I also tried to set the number of samples per channel to 2. I reasoned that with the sampling rate of 2KHz, 1ms loop should be able to pull 2data points and enqueue them. But it gave me the much-often-seen error code ":Error -200279 occurred at DAQmx Read (Analog 1D Wfm NChan NSamp).vi:1->Timed structure(s): DAQ Loop". I tried various combinations of loop time and number of samples per channel. I get Error-200279 very often. Note that I have several state transitions and only in a couple of them during every cycle of state transitions, I remove elements and flush the data queue (one place where I remove elements is shown in my original message in the picture-'Acquire Response.jpg').

How do I set the data acquisition loop to enqueue elements for exactly 1 msec or n msec so that I can control my dequeue size?

Thanks a lot, I am getting really tired of fixing this problem. Please help.

Mani

[Kevin_Price]

A few comments.  Probably not all of them will help, but hopefully at least one does...

1.  I'd gently suggest that you may be focusing on solving the wrong problem.   You're sampling at 2 kHz in hardware and trying to service the AI data in software at 1 kHz.  I don't think that's necessary.  Also, the AI data acq task itself can give you more relevant and more precise timing info than the "tick count".  As long as you are sure to accumulate *all* the samples, you know that their "dt" spacing is 0.5 msec (1 / 2 kHz) and you don't rely on the OS to give you timing info.

    The software processing rate should be driven by answering:  "When the subject moves the joystick, how fast must my program detect it and react / respond?".  You probably don't need to respond any faster than 50-100 msec or more.

2.  Putting your calls to DAQmx Read inside a Timed Loop structure may complicate things.  If you want want to collect data in 100 msec chunks, you can use a simple while loop and specify that DAQmx Read should read 200 samples.  The call to DAQmx Read will yield CPU while waiting for those samples to accumulate.  An advantage of this method is fixed-size data chunks which are often easier for processing.   The disadvantage is that you need to make sure your software keeps up with the hardware so you don't overrun the buffer.

3.  When you read the AI data, the fact that you fork the wire to both the "data" indicator and to the "Enqueue" function forces LV to copy the array of data every loop.  If you were to wire straight from Read to Enqueue with no forks (i.e., remove the "data" indicator), LV can do the enqueue without any memory copying at all.

4. When you enqueue there is a red dot meaning that the waveforms are being coerced into whatever datatype was defined when the queue was created.  Coercions can slow your code so try to resolve this.

5. Despite all these nits, I want to also add that the code looks impressively well-designed for a LabVIEW newcome.  Good work!

-Kevin P.