Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Ramp down a signal before stopping

Solved!
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
(329 Views)

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

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



0 Kudos
Message 12 of 16
(308 Views)

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
(295 Views)

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

0 Kudos
Message 14 of 16
(279 Views)

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

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW?

(Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).



0 Kudos
Message 15 of 16
(267 Views)

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.

0 Kudos
Message 16 of 16
(172 Views)