MCC USB-1808X OEM - Delay in output when changing output buffer.

[T. Hain]

Hi,

I am using a MCC USB-1808X for simultaneous out- and input of both analog channels and the digital port. I am using the python uldaq library v1.2.3. I create the buffer with the uldaq.create_float_buffer() function and start the scan using the daq_out_scan() function using the created buffer.

For a specific application I need to be able to change the output signal in a synchronous way, and sometimes as fast as possible, however, I notice that there is always a significant delay between the moment I change the buffer in my python code and the updated signal can actually measured at the output channel. So I have a couple of questions:

Why is there a delay between the time of changing the buffer, and how long is that? Does that have to do with the buffer rollover? When is the software buffer transfered to the hardware buffer and which part? And how can I manage to change my output signal at a specific point in time.

I also noticed that immediately after starting the output scan, the current_index of the get_scan_status() is very high (~40% of the buffer), and too high that it could have actually got there by scanning over the buffer with the given rate. I am a bit confused by that since I thought it would start at 0? The output signal is actually output starting at the beginning of the buffer, but that somehow does not match the current_index of the scan_status(). What is this about? And how do I actually know at which part of the buffer the current scan ist at?

 

Thank you for your help!

Edited March 1 by T. Hain

[JRys]

Immediately after starting the analog output, the driver copies a portion of the buffer. The amount it copies depends on the update rate and samples per channel. For example, if the buffer is 10000 and the index initially indicates 50000, half the buffer was duplicated and used to feed the device. You can still update that section of the buffer, but the update will only happen once it rolls over and copies that section of the buffer again. If you reduce samples per channel so that the buffer is smaller, the driver copies less, and updates to the buffer happen quickly. The device was not intended to be operated like a controller. There is no buffer on the device other than a 2k sample USB FIFO, and updating the portion of the buffer being fed to the device is impossible.