USB I/O board buffering

[DynoMan]

Hi,

I'm using a little USB-6001 board for a kind-of-real-time application, where I need to process the input values at about 10 Hz.

I have the analog read task running in continuous mode, and reading just the most recent value.

So far, it looks like DAQmxReadAnalogF64() comes back right away, but the most recent value only changes about 1/second - which makes me thing this thing is buffering everything, and not updating the buffer very often.

Thanks,

Joe

[AwakeTheField]

Hi Joe,

I would agree with you that it does seem like a buffering symptom, but in order to determine this, it would be helpful to see more of your relative code to know the context of how this function is being called. Can you attach the relative portion of your code here?

As a side note, you may find more collaboration by posting this question to the LabWindows/CVI discussion forum as well.

[DynoMan]

It is pretty simple code, setup the channels, timing, trigger, then start task as a continuous acquisition.  In a timer, I read a single set of channel values, from the most-recent sample in the buffer. Those values only change about once/second.

I changed the code to do a finite acqusition, and after the read do DAQmxStopTask() then DAQmxStartTask(), which seems to work better, but it takes about 0.015 seconds to do that.

This seems to be a problem common to every main-stream USB I/O board I have seen, they are all setup for high-speed streaming sampling, and really not very good at instantaneous sampling as is required in closed-loop control.

If anyone knows how to implement closed-loop control type read/<do math>/write functionality with these USB devices, I would really appreciate hearing about it - or, if anyone knows for sure how (on what schedule) these USB devices update the code-accessible buffers.

[AwakeTheField]

Joe,

To answer some questions about the speed at which the USB-6001 can sample, this device can achieve an analog input rate of 20 kHz. It also can transfer data from the buffer on the DAQ device to your host computer's buffer at a rate of 12 Mb/s. So you should be able to achieve an update rate much faster than the 1 Hz you are experiencing.

The issue may lie in either how your hardware timing is set-up, or how often the DAQmxStopTask() is called. If you are able to post that portion of your code on the forums, it may help the community determine what is causing the slow update rate.

As a final note, you may find it useful to check out this tutorial on doing PID closed-loop control with one of our USB DAQ devices: 

Software-Timed Closed-Loop Control

http://www.ni.com/academic/students/learn-daq/control/ 

This tutorial is based on using LabVIEW, but it is the same concepts as using LabWindows/CVI.

[DynoMan]

Alex,

Thanks for the reply, but I don't have Labview, and I can't make very much sense of the picture as shown on the example page.

My testing showed this:

a) Digital outputs are update-on-demand. Writing to digital outputs doesn't seem to actually do anything if the data does not change, as the function returns immediately. If the data does change, the write function takes about 0.001 seconds, and I get a 1,000 Hz square wave on a scope.

b) Analog outputs are the same, but seem to always actually do the write, even if data does not change.

c) Digital input reads seem to return new values at maybe 10 Hz, hard to tell given the level of testing I felt like doing.

d) Analog inputs, in continuous mode, with a 2,000 Hz scan rate and auto-sized buffers, seem to return a new value on a read-latest-value call about 1/second.  In finite-samples mode, with (2) samples at 2,000 Hz, and read-latest-value calls followed by StopTask() and StartTask() I get new values at about 60 Hz, with most of that time spent on the StopTask() / StartTask() pair.  This is a common problem across vendors for USB analog inputs, since everybody likes to talk about high speed acquisition (throughput), at the expense of slow instantaneous updates (latency). If you know a way around this, please tell me, but I think it is fairly deep in the driver logic.

Joe

[ZoeBoh]

Hey Joe,

From what you've said about the application you're trying to implement, it's looking like the USB 6001 may not have the right functionality. The testing that you did sounds approximately right, because USB devices aren't meant for rapid or deterministic applications like closed loop control.

Since USB is apt to have a lot of jitter, we estimate around 10 ms between when you request the sample and when it arrives at the device, but it could be more or less than this. This isn't a problem if you're trying to stream data, since we can buffer it and transfer large chunks at a time. If you're looking for a more deterministic reading, we do offer devices that are designed for that purpose. You may want to look at our cRIO, myRIO, or R-series platforms if the latency is important to you. 

Zoe B.