Slow task ‘DAQmx Read.vi’ causes error 200279

[WENGQQ97]

Hello, recently I’m replacing some old computers in our lab with Dell OptiPlex 7080 (windows 10 system, Labview2015 academic version, DAQmx15.0). PCI-6221 is installed inside. When I run our program, error 200279 occurs, which means that the buffer is overflow. This issue happens in most of new computers (no matter whether the labview / DAQmx / Windows are updated or not) except the old computers and one new computer (no update of labview / DAQmx / Windows).

The program works normally with USB-6008 in all computers, so the problem only happens when program reads data from PCI-6221. I test NI example ‘Analog Input - Voltage and Thermocouple in a Single Task.vi’ and same issue happens. Error 200279 also pops up when it reads data from PCI-6221 (This PCI-6221 has been proved to works normally).

I troubleshoot the program and find the task ‘DAQmx Read.vi’ takes much longer time (more than 100ms) to finish reading in every iteration than it’s supposed. Does anyone know why the same program works differently with PCI and USB data loggers? And, can some parameters or setting in the computer cause this issue (only one computer works, and others don’t)?

Thanks.

[ZYOng]

See Error -200279: Unable to Keep Up with Acquisition in DAQmx.

The Sample Rate and Number of Sample Per Channel inputs for DAQmx Timing VI, as well as Number of Sample Per Channel input for DAQmx Read VI play an important role here.

[WENGQQ97]

I understand how it happens and have tried to adjust those parameters but no luck. My problem is that the task 'DAQmx read.vi' takes long time (more than 100ms for every iteration) to read, so no matter how I adjust those parameters (unless I set sample rate to very low value), error 200279 will always happen. As I said, only one new computer (same program and computer hardware) can work properly and every iteration of program in that computer takes only around 0.13ms, so I wonder what will make the reading times so much different.

[ZYOng]

Can you show what values did you use for those three parameters?

Here is an example of how those parameters work. For sample rate of 1k and the number of sample per channel (which determines the buffer size for continuous mode) of 2k configured for Timing VI, if you use Read VI to read 100 samples, the Read VI will take 100/1000 = 0.1s to execute each time. If you don't use Read VI to retrieve data from the buffer, the buffer will be overflown after 2k/1k = 2 seconds.

[WENGQQ97]

Hello ZYOng, Thanks for your explanation.

 Now I know how much estimated time one iteration should take. My settings are 2000(sample rate) and 320 (number of sample). I test the iteration time again and see what I got shown in the attachment. The working one (159.9ms/cycle) is closer to calculated time than not working one (158.1ms/cycle). I don't know what causes this difference and whether it's the cause of my problem. Thanks.

[DerrickB]

I'm confused how you're saying it's running slow. 320/2000 = .16 seconds per 320 samples (160ms) but one of yours is reporting 159 and the other 160. It looks like the only difference is because of how you're tracking the cycle count yourself and using that as the divisor for the loop time. One of them has way fewer iterations than the other so what looks like you're off-by-one error for the divisor means your ms/cycle will continually trend towards 160. You'd be better off taking the time difference between iterations and passing it through an averaging node to get a readable value, or throw the time delta value into a chart so you can see exactly what's happening each iteration. The chart is also immensely helpful in know exactly what happens the few iterations before an issue, no averaging of cycle times over an entire run to cause you to lose details.

[ZYOng]

I would say the milliseconds of difference is expected considering that Windows is non-deterministic by nature and has roughly 1ms of timing resolution. See Accuracy of Software-Timed Applications in LabVIEW. Not to mention that you have so many post-processing algorithm in the same loop.

If you need the timing information for data processing, you can safely assume that dt between samples has high accuracy (at the level of nanoseconds). DON'T use the software timing from the operating system.

[Kevin_Price]

You've gotten a lot of good info & advice to help solve your problem.  But if still stuck, please post your actual code and describe your problem in plenty of detail.  But first:

• if using parameters from front panel controls, make sure to set your working values as the defaults
• back-save to LabVIEW 2018 or earlier.

-Kevin P

[WENGQQ97]

Hi Derrick / ZYOng, Now I realize that DAQmx Read.vi is running at expected speed before problem happens. You are correct about the cycle time trend to 160ms if they can run normally for a while. I'm still beginner to Labview and will try to do as you suggest. I will update here if I find out what causes this issue or there is any progress. Thanks.

[WENGQQ97]

Hi Kevin, those parameters are constants and my LabVIEW version is 2015. I will do more test to get more detail about this problem. Thanks for your message.