BUG? USB6009 stopping acquisition randomly on it's own

[dthess]

I'm having a random bug here by the USB6009 during acqusition.  There are no error codes.  It just stops collecting. 

If I collect by start of the PFIO trigger everything is fine.  However if I immediately start w/o a Trigger, it just randomly dies. 

Function calls to :  

DAQmxErrChk (DAQmxGetReadAttribute(m_hNIAITask, DAQmx_Read_AvailSampPerChan, &iRead, 0));

Constantly return 0 for iRead after a few reads.  I am certain the buffer is no overfilling.

//cChan = "Dev1/ai0" or cChan = "Dev1/ai1"

//m_dwBaseSampleRate = 10000

if (m_bHardwareMode) {

  DAQmxErrChk (DAQmxCreateTask("AI",&m_hNIAITask));

  DAQmxErrChk (DAQmxCreateAIVoltageChan(m_hNIAITask,cChan,"AIInput",DAQmx_Val_Diff,f64Min,f64Max,DAQmx_Val_Volts,NULL));//:Dev1/ai1

  DAQmxErrChk (DAQmxCfgSampClkTiming(m_hNIAITask,NULL,(float64)m_dwBaseSampleRate,DAQmx_Val_Rising,DAQmx_Val_ContSamps, m_dwBaseSampleRate * 100 ));

  DAQmxErrChk (DAQmxStartTask(m_hNIAITask));

  DAQmxErrChk (DAQmxSetReadAttribute(m_hNIAITask, DAQmx_Read_RelativeTo, DAQmx_Val_CurrReadPos));

  }

[dthess]

//The rest of the code sets up analog out for trigger

//Set up output

f64Min = 0.0;

f64Max = 1.1;

if (m_bHardwareMode) {

  DAQmxErrChk (DAQmxCreateTask("AO", &m_hNIAOTask[eChannelAO0]));

  DAQmxErrChk (DAQmxCreateAOVoltageChan(m_hNIAOTask[eChannelAO0],"Dev1/ao0",NULL,f64Min,f64Max,DAQmx_Val_Volts,NULL));

  DAQmxErrChk (DAQmxStartTask(m_hNIAOTask[eChannelAO0]));

}

//Start read loop thread

[dthess]

Can someone give me a possible clue to look for?  Is there a function to tell if the channel task is still running?

I have dumped a trace log. I am not stopping the task, or clearing the task handles.

Message Edited by dthess on 01-19-2009 12:21 PM

[Jordan F]

Try one of the shipping examples for DAQmx that does not use an external trigger and see if you still see the same behavior.  If you are using LabWindows an example you could try is located in Help>>Find Examples>>Hardware Input and Output>>DAQmx>>Analog Measurements>>Voltage>>ContAcq-IntClk.proj.  Otherwise, you could try a C example which is located in

Location of ANSI C NI-DAQmx Shipping Examples and DAQmx Library File for Windows

http://digital.ni.com/public.nsf/allkb/FB26BDA52FFFD4EE86257124005C36C3?OpenDocument

[dthess]

The stop acquriing data problem is now manifesting itself with triggered runs, as well as non triggered runs (on a less regular basis.  Maybe 1 out of 200 data runs)

Are the USB6009 drivers certified for multithreading?  I have one thread driving an analog out (AO0), and another thread reading analog in (AI0).  This is set up as a external loopback test.

Don Hess

Message Edited by dthess on 01-29-2009 10:28 AM

[dthess]

BTW: I'm using the 8.6 version of the software.

[dthess]

We're doing an intense amount of processing and UI update, while reading in at a high sampling rate (40kS/s), and outputing on two additional seperate threads in near real time.  This is pegging out the CPU.

I failed to receive any error message when trying to acquire data, except for once about a hardware buffer overflow.

I'm going to lower the CPU load by reducing screen updates and see if this solves the problem over the next week. 

Are there any additional functions I can call to check the internal status of the USB6009 hardware besides DAQmxGetTaskComplete?