DAQ read freezing

[LonelyHunter]

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!

[santo_13]

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

[mcduff]

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?

[LonelyHunter]

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! 

Thanks for your help!

[mcduff]

I would suggest taking everything out of the loop except the read and testing. Even better, open the example finder and run the Voltage continuous acquisition example and see if you can hit a 50 Hz rate. I suspect yes. There is a lot going on in your picture that raises my eyebrows. 

[LonelyHunter]

Hi,

Thanks again for taking the time to help me!

I just tried the Voltage example VI and I can run 1500 Hz while reading 1 data per read without any apparent delays/freezs. 

I will try to move everything out of the loop in my original VI (i.e. data processing, although simple, in another loop).

But my original question remains. Why does using the -1 option work well but specifying a specific amount of data freezes? I would have expected the -1 option to be more consuming. 

is it possible that by specifying "read all available data", the DAQ time chip is not being used because it just "reads whatever there is" and when I ask the DAQ to read a small amount of data points, the timing chip becomes crazy with what's in the background?  However, the results with the -1 option suggest that what's in the background isn't consuming too many resources. 

Thanks!

[mcduff]

---

@LonelyHunter wrote:

is it possible that by specifying "read all available data", the DAQ time chip is not being used because it just "reads whatever there is" and when I ask the DAQ to read a small amount of data points, the timing chip becomes crazy with what's in the background?  However, the results with the -1 option suggest that what's in the background isn't consuming too many resources. 

---

I am not convinced it is running as you think with the -1 option.

Put the following code in your loop. Right-click the wire to the indicator and choose Custom Probe > Controls > Waveform Chart. Monitor the loop speed and see what it does.

You would need to post some code for a better answer. For example, do any of the subVI operate in the UI thread, is there some other blocking code in there. From your picture you have unwired indicators, controls, and property nodes. Hard to tell what is wrong.

[LonelyHunter]

FYI;

When collecting 150 data at a time. Here is an example of the freeze I'm getting. 

Again, wend using the -1 option, there is no delay. It all runs smoothly in 2-3 ms. 

I will try to simplify the project to send it here.

Thanks!

[mcduff]

Do you have any property nodes in your subVIs? Is your queue or notifier stuck waiting and nothing can proceed in your loop?

[LonelyHunter]

Hello again,

I did remove all superfluous action in the background. The subVI being called after the reading are in an "off" case structure so they are not called. 

I then added a flat structure to isolate where the problem is.

I stopped the VI during a freeze and found that the millisecond timer value 3 was different than the two others. It didn't update. 

This suggests that the subVI DAQmx Read is slowing down randomly. Now, I understand that what's happening in the background can influence the loop speed, but it always stops at the Read moment even if it's the only action happening.  

And to answer the question, no property nodes are being used in the background of that loop other than what's on the picture. I have some parallel loops running of course.

Could it be a driver issue? It's up to date.