Multifunction DAQ

Showing results for 
Search instead for 
Did you mean: 

Ramp down a signal before stopping

Go to solution

EDIT: Actually it is working, but it takes 10 seconds (!) for the write to have an effect. I was hoping to have an effect within one or two cycles of the buffer but it's 10 cycles. The properties of the running task are as follows:


DeviceScalingCoefficients: [1×1 System.Double[]]
MemoryMappingEnable: 0
UsbTransferRequestCount: 4
UsbTransferRequestSize: 32768
DataTransferRequestCondition: OnBoardMemoryNotFull
DataTransferMechanism: UsbBulk
UseOnlyOnBoardMemory: 0
ReglitchEnable: 0
DacReferenceValue: 10
DacReferenceExternalSource: [1×1 System.String]
DacReferenceSource: Internal
DacAllowConnectReferenceToGround: 0
DacConnectReferenceToGround: 0
DacRangeLow: -10
DacRangeHigh: 10
Resolution: 16
ResolutionUnits: Bits
TerminalConfiguration: Rse
CurrentUnits: Amps
VoltageUnits: Volts
OutputType: Voltage
CustomScaleName: [1×1 System.String]
Minimum: -10
Maximum: 10
MSeriesLegacyCompatibility: 0
Description: [1×1 System.String]
PhysicalName: [1×1 System.String]
Type: AO
IsGlobal: 0
VirtualName: [1×1 System.String]




It is DAQmx version 21.3.0 and a USB-6361

0 Kudos
Message 11 of 16

Ok, good.  It's working conceptually, but with too much latency.  The culprit is going to be the various extra buffers between what you write to the task and the output signal itself.  We have to prevent DAQmx from making these buffers too big so they take too long for data to work through.


1. Change "DataTransferRequestCondition" from OnBoardMemoryFull to OnBoardMemoryEmpty (or similar, I don't know what the syntax will be from Matlab).

    Alternately, see if you can set the Onboard buffer size explicitly and make it significantly smaller than max.  First try these things one at a time b/c I kinda expect only one of them to work.  I'm just not sure which one offhand.


2. I haven't tinkered with the USB settings but my semi-educated guess is that you may also need to reduce the USBTransferRequestSize significantly.  This property seems to set the size for an extra stage of buffering that applies only to USB devices.  Here's how I think it works:

a. you write data to the task with a DAQmx Write function call

b. the driver is working on pushing next-in-line data from the USB Transfer buffer down to the device's onboard FIFO via USB.

c. it then tries to keep the USB Transfer buffer filled up by pulling next-in-line data from the task buffer


Limiting the size or usage of the Onboard FIFO buffer and the USB Transfer buffer are where I'd be focusing.


I'm not sure what the USBTransferRequestCount property does.



-Kevin P


Present job ending soon. Need DAQ expertise? PM with serious opportunities.
0 Kudos
Message 12 of 16

Yes, definitely good news. In fact, even better news is that I tried it with a PCIe DAQ at 1 MHZ sample rate and it works perfectly as far as I can tell (pending careful latency checks with a stop trigger). So I'll play with the settings you describe to see if I can get the USB DAQ working well, as that is my ideal device. Otherwise I think I have a functional solution. Hopefully next week we will know. 

0 Kudos
Message 13 of 16

This all in fact does work on the USB DAQ also. 

0 Kudos
Message 14 of 16

Which particular thing(s) "worked" for your USB DAQ?  What buffer management settings did you have to control (if any), and how?


Can you post your resulting code?  It could help the next person coming along needing to see a working Python example.



-Kevin P

Present job ending soon. Need DAQ expertise? PM with serious opportunities.
0 Kudos
Message 15 of 16

The example is here:


It's not Python, though. It's MATLAB with a .NET interface to DAQmx.

Message 16 of 16