DAQmx delay in reading?!!

[ballbouncing]

I have a very simple appicaltion of reading the position data from an encoder and I am using the Linear encoder DAQmx with other complementary blocks in my application.

This position data is simply projected on the monitor, by the vertical movement of a rectangle, you can see the attached vi.

Unfortunately the projected displacement information on the screen is something in the order of 50 msec delayed. I mean when I turn the encoder as an input, that specific data is on the monitor after almost 50 msec!!

I have been working on this for a long time but I still can not even reduce this number.

Is there anything I can do make this simple applciation more real-time?

I appreciate any kinds of helps and notes in this area.

[bstreiff]

What DAQmx device are you using? A USB device will exhibit greater latency than a PCI/PXI one.

Is the latency you're referring to between when the event happens and the DAQmx Read completes, or between the DAQmx Read and the picture control being updated?

How quickly are you expecting any particular iteration to complete? Perhaps you should consider separating your drawing code from your main loop.

[Beutlich]

The attached VI is set to collect an array of values before sending the data back to the computer. The 50 msec makes a lot of sense because this value defaults to 1000, and you have a sampling rate of 100khz, so that's definitely 50msec ballpark (factor of 2 off, maybe from the quadrature encoding). You can set the value to be single point acquisition to send the most current value to the computer always, or you can change the 'samples per channel' terminal on the DAQmx Timing VI, maybe try 20 instead of 1000.

[ballbouncing]

Dear Sir,

yes, it is a USB 6229 BNC device.

the latencey is just in reading the data using daqmx not in picture updating. the loop alone without daqmx works pretty fast.

I definitely expect less than that. I don't mean 0 delay. but as low as possible.

Thanks.

[Beutlich]

The delay in the DAQmx task is because the DAQmx task will wait until the board collects 1000 samples (the default for 'samples per channel'). Changing this property to a lower value will probably accomplish the behavior you are looking for.

[ballbouncing]

I already tried that. The single sample data reading is also slow. in that case it seems that labview is trying to control the hardware by the loop, 'software controlled'. 

While in the current setup the data acquisition system is controlled by its internal clock, so I expected the lower delay. 

I also reduced the buffer size, but the delay gets larger. actually this is the minimum possible buffer size for the vi to work. lower than this number it freezes and it doesn't move at all.

Thank you for your attention.

[ballbouncing]

I have changed the samples per channel of the DAQmx Timing block to 20. But the delay hasn't improved.

Should I change the sample per channel of the DAQmx read inside the loop. the default value is -1. I set this number to 20 but the paddle freezes!!.

what about the buffer size? should I change that too?

Thanks Eric.

[Beutlich]

There can be delays like this if you have the data acquisition and some image processing (or any heavy processing). There isn't any obvious processing in the loop it seems, but maybe the picture control and indicator may be causing some image processing(copying) just more the data down the wire. Do you get the same delay if you run the example VI Measure Angular Position.vi with the device? This can isolate just the acquisition to identify the source of the delay.

[ballbouncing]

Dear Eric,

I have just tested the "Meas Angular Position-Buffered-Cont-Ext Clk.vi". I set the clock to 100KHz and also the sample per channel to 20. So this vi does not have graphical presentation but just the numeric indicator.

The problem still persists.

any other thoughts?

by the way, could you tell me the difference between the buffer size and samples per channel?

and what should I set for the samples per channel in the read vi block inside the loop.

[Beutlich]

I really like the article Samples Per Channel Input of -1 On the DAQmx Read VI, which discusses the samples per channel and the buffer. I'd like to also recommend the article DAQmx Timing and Sample Rates, which talks about delay time that occurs on the hardware device and the delay time associated with software access.

The second article is actually really good, and has a blurb about timing:

"How Fast?
The rate at which the samples are read from the hardware buffer on the DAQ board to the software buffer is dependent on how often the Read VI is called.  Since the DAQmx Read VI is often in a while loop, the loop rate will determine how often the DAQmx Read VI is executed.  The speed of the software will also be dependent on the speed of the processor and the number of processes occuring at a time. "

I'm guessing the measured delay is not due to the processor, so I'm guessing it is due to the configuration of the hardware buffer (the matching of parameters for the samples to read and rate).