Read DAQmx: timeout too long

[Baobob]

Hello,

The DAQmx Read VI does not seem to take the timeout I set into account: when the connection with my cDAQ 9181 is lost, I would like the Read VI try only once to read the data and quicly return an error instead of waiting for 10+ seconds.

The attached screenshot summarizes the problem: I let the while loop run for a while normally before to unplug the ethernet cable from the cDAQ to simulate a network failure. As you can see, it took more than 18 seconds for the Read VI to return an error although I set the timeout to 1 second.

I am obviously misunderstanding something, but what?

The module is a NI-9206

Thank you!

[John_P1]

That seems like a bug to me, I don't think you're misunderstanding anything.

Try this (no guarantees):

Configure sample clock timing before starting your task (continuous, 1 Hz).

Take out the 1 second wait in your loop.

Best Regards,

[Baobob]

Hello John, thank you for your answer,

I tried what you suggested, the VI still waited for a considerable amout of time (11 seconds while the default timeout for the Read VI is 10 seconds). See attached screenshot.

Thanks

[ben64]

---

@Baobob wrote:

Hello John, thank you for your answer,

I tried what you suggested, the VI still waited for a considerable amout of time (11 seconds while the default timeout for the Read VI is 10 seconds). See attached screenshot.

Thanks

---

The 1000 ms wait is useless and may occur before the DAQmx Read vi adding an extra secondif so. The DAQmx Read.vi will wait until data is received or 10 sec and then generate an error.

Ben64

[John_P1]

---

@ben64 wrote:

The 1000 ms wait is useless and may occur before the DAQmx Read vi adding an extra secondif so. The DAQmx Read.vi will wait until data is received or 10 sec and then generate an error.

---

It's true the 1000 ms wait is useless, but I wouldn't expect it to add to the loop time since it is executing in parallel with the read.  In any case, the obvious thing to try is lowering the read timeout and see if the actual delay scales with it.

I once had a similar problem using VISA with an LXI instrument, the timeout used for network communication was a system parameter somewhere in the Windows registry (it was a while ago, sorry I can't be more specific) rather than the VISA timeout that was configured in software.

Best Regards,

[Baobob]

---

@John_P1 wrote:

---

@ben64 wrote:

The 1000 ms wait is useless and may occur before the DAQmx Read vi adding an extra secondif so. The DAQmx Read.vi will wait until data is received or 10 sec and then generate an error.

---

It's true the 1000 ms wait is useless, but I wouldn't expect it to add to the loop time since it is executing in parallel with the read

---

John, I would have agreed with you, but following Ben's suggestion, I removed the Wait 1000 ms and the last iteration of the while loop indeed took about 10s to complete. I don't understand that at all. If somebody could explain...

Now if I use a timeout equal to the inverse of the rate, the VI timesout as expected (see attached screenshot). Thanks guys, I wish I could mark two posts as solution.

[ben64]

I may be wrong but I doubt LabVIEW will parallelize two functions that are in the same while loop.

Ben64

[Baobob]

To answer your question:

[0utlaw]

The functions will execute in parallel- the issue is that the 1000 ms wait will always take slightly longer than 1 second, whereas the DAQmx read takes any amount of time up to the timeout (one second).  Eventually (and I'd guess sooner rather than later, maybe a couple minutes or so) you reach a point where the samples are available before you attempt to read them.  Not really an issue because you're only sampling at 1HZ- the sample buffer can probably take it (hah).  As soon as we get into this scenario, the DAQmx read returns a value immediately when we call it (and updates the MGI timer) but we still have most of a second left waiting for the wait function to finish, so the next time we update the timer it will be +1 second. 

Removing the wait function means that we will always be waiting/ready for a new sample to be available, rather than having one in the buffer before we attempt to read it. It looks similar, but we're sampling and updating the timer closer to when the loop exits, rather than closer to when it begins executing.

Regards,

[Mark_Yedinak]

---

@ben64 wrote:

I may be wrong but I doubt LabVIEW will parallelize two functions that are in the same while loop.

Ben64

---

The LabVIEW scheduler is designed to run any node that is ready to execute (all inputs are satisfied). Therefore nodes within a single loop with no data dependency can and will execute in parallel. LabVIEW has some rather complicated ways it determines things are nodes. For example a While loop and all of its contents are considered a node however it contains nodes itself. The basic rule of thumb is anything and everything can run in parallel provided there are no data dependencies and all of its inputs are satisfied.