DAQmx Base DMA error 42: DMA Channel in wrong state

[cericdahl]

I am using a PXI-6115 board on a Linux machine (RHEL 5.2) with DAQmxBase 3.2.0f1, attempting to run the example vi:

examples/daqmxbase/dynamic/ai/Acq&Graph Voltage-Int Clock-Dig Ref.vi

reading out short waveform from a single channel with external reference trigger.

I receive the following error:

Error 42 occurred at RLP Invoke Node:

The DMA Channel is in the wrong state.  The DMA Channel may need to be Reset.  Or you may have secified an invalid DMA Mode, or a DMA Mode which has not been implemented yet.

Delving into the example code, the errors occurs in the DMA Scarab Read routine, in DMA Scarab Move, when calling DMA Start.  DMA Scarab Move runs successfully earlier when it's called to initiate the DMA transfer, but once initial Scarab Move has been read and more data is required from the Scarab, this error crops up. Interestingly, when DMA Scarab Move runs the first time, it often moves only a small chunk of data into the DMA buffer, much less than the buffer size...  this doesn't give an error, but might be related?

Any help is appreciated-  Since this is an NI example vi, this is hopefully easily reproducible...

[ManLongAtNI]

I have brought this to the attention of R&D and will post as soon as I have some information.

Regards,

Glenn

Applications Engineer

National Instruments

[ManLongAtNI]

I was able to duplicate your issue and I have filed CAR(Correcive Action Request) #181577  to address this issue. You may reference this id number in future releases of the driver to check whether or not the issue was fixed.

In the meantime, you can try the following workarounds for your application.
1) Use Start Trigger
2) Set-up a software trigger using a Digital Read. {Due to single-threading in DAQmx Base, latency can occur between the trigger and the analog input}
3) Acquire all samples and ignore unwanted samples

4) You may want to consider switching distributions(Mandriva, SUSE) so that you can use DAQmx 8.0.1 and get full support.

Regards,

Glenn

Applications Engineer

National Instruments

[cericdahl]

Thanks for checking this out, Glenn -- I think I see how to make option (3) work out (and I'll have to find out if (4) is an option for us or not...)

-Carl

[cericdahl]

Hello, just an update for anybody following this problem:

 The problem seems to have been solved by inserting a call to "SSeries-- AI DMA Channel Config.vi" just before "SSeries-- AI DMA Transfer from Scarab.vi" in "SSeries-- AI Scarab DMA Read Samples.vi".  I haven't tested this extensively yet, but so far I seem to see the correct functionality.

[JoeFriedchicken]

Thanks, Carl. We've made a note to your workaround and will investigate its robustness when we enter the next development cycle.