DAQmxBaseReadAnalogF64 hangs forever without a trigger

[jhfrontz]

Is there something in the semantics of DAQmxBaseReadAnalogF64() that says "if you've set up a trigger for the data collection, DAQmxBaseReadAnalogF64() will never return, no matter how short the timeout, until the trigger is seen"?

We have a scenario where sometimes the trigger doesn't arrive and were expecting DAQmxBaseReadAnalogF64() to return a timeout indication.  However, it seems to hang forever.

Is that the intended behavior?

Thanks,

Jeff

[Efrain_G]

Dear Jeff,

The DAQmxBaseReadAnalogF64() fucntion is supposed to send an error after the timeout has elapsed. In fact, you can specify the time you want to wait before the timeout occurs. Have you specified any wait time for the timeout? It might be that there is no timeout by default.

What board are you using?

[jhfrontz]

Definitely spec'ing a timeout, typically in the 60 second range.  It works fine if the trigger is observed (e.g., it will return a timeout indication if the operation is still in progress).  We're using the usb-6218.

Jeff

[Efrain_G]

Hey Jeff,

From my understanding, the expected behavior for this function is that after a trigger has been received no timeout should occur because the timeout is referenced to the trigger. I guess I am not quite sure what you are looking for in your application. Are you sampling continuously? What kind of trigger are you using? (level trigger, digital trigger) Are you reading a finite number of samples or continously?

[jhfrontz]

We're doing one-shot sampling (finite sample size), digitally (rising-edge) triggered.

My experience is the exact opposite of what you suggest-- if the trigger is known to have been asserted, we can get a timeout to happen (e.g., by specifying a timeout value that is sufficiently less than the remaining sampling duration); if no trigger is asserted, there's never a timeout (the read just hangs forever until we do a device reset).

Jeff

[Efrain_G]

Jeff,

I think we will need more information from you to figure this out. What is the Operating System that you are using? (MAC, Linux) How many samples and what is the sampling rate that you are using?  Feel free to post your code as well. Are you using any of our DAQmx Base examples?

[jhfrontz]

Using Linux (2.6.23).  Sample length and sample rate seem to have no affect on the problem, but I just tried a 1 second sample length at 1000Hz.  Then a call to read with a 60000 ms (60 second) wait-- it never returns.

Jeff

[jhfrontz]

Also, are the semantics such that operations "stack" on a task or are they all simultaneous?  Could it be that we're setting up the data collection, then setting up the trigger, and then starting the task (vs. setting up the trigger and THEN the data collection)?

I'm trying to make sense of inherited code, so I don't necessarily have a complete understanding of the NI task paradigm.

Jeff

[Efrain_G]

Jeff, These operations do not run simultaneously. Every line of code executes after the previous one. Therefore, you are right as far as worrying about the order of execution of your code. I believe that it will be easier if you post your code here so we can take a look at it.

[John_P1]

Then a call to read with a 60000 ms (60 second) wait-- it never returns.

What exact number are you passing for the timeout to DAQmxBaseReadAnalogF64?  It sounds like you might be passing 60000 but the value is supposed to be in seconds.  If this is the case, the function should eventually time out after about 16 hours, 40 minutes.

From the DAQmx Base C Reference Help:

timeout

float64

The amount of time, in seconds, to wait for the function to read the sample(s). This function returns an error if the timeout elapses.

Best Regards,