LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQ read freezing

Hello,

I've been using a producer/consumer loop for the past three years without issues. This month, I increased my sampling rate from 100 Hz to 1500 Hz and encountered a problem with my VI. My DAQmx task is set to continuous nChan nSample.

 

I run biofeedback experiments, meaning participants see real-time data on a monitor. The issue arises when I read 30 samples at a time from the DAQ buffer (equivalent to a 50 Hz display rate). I experience random freezes lasting over 2 seconds. However, I don’t lose data since the DAQ continues recording into the buffer, which I’ve sized at 15,000 samples. But a 2-second freeze is far from ideal for biofeedback.

After extensive testing, I found that the DAQmx Read VI is responsible for the freeze—it’s not caused by other parts of my code. When I isolated the issue, everything pointed to the DAQmx Read VI itself.

 

Interestingly, when I set the read parameter to "Read all available data" (-1) or use the AvailSampPerChan property, everything runs smoothly. The only drawback is that my producer loop starts running at 3000 Hz, likely because when there’s nothing to read, the iteration continues instead of waiting. While this works, it doesn’t seem like the most efficient solution.

 

I was previously advised against using AvailSampPerChan, though I don’t recall why.

While I’m glad that the -1 input resolves the issue, I don’t understand why specifying a fixed sample size causes these freezes. It feels as if my DAQ’s internal clock is malfunctioning.

 

Any suggestions on what could be causing these freezes?

Thanks!

0 Kudos
Message 1 of 4
(43 Views)

Please attach your VI and what DAQ model are you using?

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 2 of 4
(40 Views)

There is overhead every time you call a read. A good practice is to read 100ms of data in your loop. This will update the display at 10 Hz and is usually sufficient.

 

Is there a reason you need to update at a faster rate? Your subjects cannot perceive 50 Hz update rate; movies are at 25 - 30 Hz rate, you can go that high if needed.

What else is going on in your read loop?

 

For really high sampling rates, in the MHz range, you may need to read less than 100 ms of data, but that is not the case here.

 

Lastly are you using a networked device?

0 Kudos
Message 3 of 4
(28 Views)

Hi,

Thanks for your input. I should have indeed specified it. I'm using a USB 6001.

 

After pilot testing, we found that 50Hz was more natural than 25. 10 Hz is too low for sure. Anyways, feezes happened when reading 100ms of data too (but not with 1000ms). But again, when I read all the available data (-1), everything works well. No freezes. Maybe my wording is not good. The VI do not freeze. It's the ReadVI that stops reading... it waits for 2 s before continuing (although it is set at 30 data to read). When the ReadVI freezes, the project VI is still working.

 

Yes, stuff is happening in the background, but the loop can be done in under 5 ms when I use the "read all data available" option. Furthermore, the freezes happen when the Read VI is being called, not when something else is happening in the background. Also, it is random. 

I did some troubleshooting to isolate the problem to the Read VI. I used a flat sequence with the ReadVI in the middle of the sequence. When the data collection is frozen, the indicators before the ReadVI are updated, but not after. 

 

My VI was not included because it is part of a project of more than 50 sub_VI and controls. But here is a picture of the page that includes the Read VI, if it can help! 

LonelyHunter_0-1739327516540.png

 

Thanks for your help!

0 Kudos
Message 4 of 4
(16 Views)