Ramp down a signal before stopping

[bobcampbell]

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

[Kevin_Price]

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

[bobcampbell]

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. 

[bobcampbell]

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

[Kevin_Price]

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

[bobcampbell]

The example is here:

https://github.com/tenss/MATLAB_DAQmx_examples/blob/master/code/%2Bnidaqmx/%2BAO/hardwareContinuousV...

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