Problem acquiring more than 1000000 samples

[Neil_S.]

Dave,

Thank you for posting the simplified code.  It made it very straightforward to reproduce the problem.  I was even able to reproduce the problem when using a simulated S-Series.  An interesting thing to note is that the same code does not cause any issue if you are using a simulated M-Series.  Just the 6120.  Weird.  Also weird is the fact that the same task configuration works fine in MAX.  I will post again today and let you know if we find a suitable workaround.

Regards,

Neil S.
Applications Engineer
National Instruments

[Neil_S.]

Dave,

I missed the guys from R&D yesterday but will try to get a hold of them today.  I will let you know.

Regards,

Neil S.
Applications Engineer
National Instruments

[Neil_S.]

Dave,

The engineers in R&D seemed to agree that this behavior is not intentional.  This was reported to R&D (# 459EOPVF) for further investigation.  A possible work around will be to use the ReadMultiSample method of the AnalogMultiChannelReader to determine when the task has completed.  If you specify the same number of samples to read as the number of samples that the finite task is configured to acquire then the ReadMultiSample method will not return until all of the samples to acquire are available (i.e. the Task is Done).  If you need a thread different from the reading thread to know about the task completing you will need to send an event, queue or notifier to the other thread to alert it of the completion of the DAQmx Task.  This is obviously not the perfect work around but may allow you to get you off and running on your current application.  If this will not work for your application let me know and we can explore if there may be other possible workarounds.  Thank you so much for your feedback!  Hopefully this issue will be resolved in a future release of our driver.

Regards,

Neil S.
Applications Engineer
National Instruments

[DAQAroundTheClk]

This has been an interesting thread.  Here's a couple of workarounds you can try: Try explicitly setting the input buffer size property to the number of samples per channel you are acquiring in your finite acquisition before you start the task.  For example, if you are performing a finite acquisition of 1,000,001 samples/channel, use the DAQmx Configure Input Buffer VI or corresponding C/CVI/VB function to set the value to 1,000,001.  Less desirable than that workaround, but another one to try (if applicable for your device) is to set the Data Transfer Request Condition to Interrupts instead of DMA and see if that causes the done event to report correctly.  I'd be interested to hear the results.

[drotarj]

Check the thread:

http://forums.ni.com/ni/board/message?board.id=250&message.id=27238

I am having a similar problem with a PXI-6132.

Jason

[drotarj]

I tried setting the buffer size manually with DAQmxSetBufInputBufSize, and it seems to have solved my 1 MS limit problem. I guess there must be a problem with the automatic input buffer allocation in NIDAQmx.

Jason

[DaveG-GJ]

DaqAround,

You are right.  Thank you very much

Explicitly setting buffer size with AITask.Stream.Buffer.InputBufferSize to the finite number of samples to acquire fixes the problem.  I have not tried the workaround on my other system but I am confident it will work.

I am unwilling to try the interrupt-driven transfer because even my existing solution with DMA transfer is slow enough to be marginal. 

The workaround I was using was to set AITask.Stream.ReadAllAvailableSamples to false and then to just call AIReader.ReadMultiSample(-1) and to wait.  That also worked but it did not allow me to gain control the instant the ADC was done with conversion so I could record a CPU time tick.  You solution gets me to the same place I wanted to be.  Thanks again.

Dave George

970 263 9714