Data acquisition data loss issue

[Serge67]

I have a data acquisition system built in LabVIEW 2011 and running two MCC USB-2533 boards in master-slave configuration collecting up to 128 channels of analog input data. The processing is very simple - some averaging, statistics, etc and the data is stored in csv text files at fairly slow rates - 10 samples/sec. CPU load is under 40%. The program is using producer-consumer architecture and it uses queues for data transport between the processes. Everything is optimized - no new arrays allocation within any of the loops, no tight loops, no unjustified data movements. The program works flawlessly on a standalone PC disconnected from network and there are no data gaps in the data files.

However, the customer's system is installed in remote location and it absolutely has to be connected to Internet for periodic data uploads and for remote desktop connectivity, the only way to access the system. That's where the trouble begin: it loses data randomly 2-3 seconds at a time, sometimes as much as 20 consequitive seconds. From my investigatiuon it appears that the polling loop checking for board status and for availability of new data just stops running leading to a buffer overrun. I suspect that it has to do with Windows tasks and priorities that my data acq program stops being served by Windows briefly. How to avoid it? My data acquisition vi is set to data acquisition Preferred Execution System and all sub vis set to be reentrant as they are used in parralell for both boards. One way I can reliably repeat the data drop issue is when I connect to data acq system via remote desktop. It takes about 20 seconds to make initial connection and I always see 2-3 seconds loss of data during that time. I am sure there could be other distractions that would keep Windows from serving the data acquisition thread and cause gaps in the data. This happens on Windows XP SP2 embedded, Windows 7SP1 Embedded and Windows 7 SP1 full Professional version. The type of CPU doesn't seem to make a huge difference - it happens on Atom, on i5 and on i7 and on the two latter ones CPU utilization remains 2-3% at most. I have tried setting program priority to high and to Real Time in Windows Task Manager, but it didn't make much difference. The Real-Time priority actually made it worse - I got more data gaps than in Normal priority.

Is it entirely Windows issue or Windows-LabVIEW interaction issue? MCC support engineer couldn't offer any usefull advice: as long as the system worked in a standalone mode he was satisfied that there was no issue with neither boards nor driver and SDK.
Any help and suggestions would be greatly appreciated.

[inniwhoni]

Hi Serge67,

The problem you're seeing is probably coming from the remote desktop. When you connect to Windows remotely it's going to need to manage the remote connection which is causing jitter with your application. Essentially the remote connection causes the DAQmx Read.vi to run less often so the buffer fills up and you get the buffer overflow error and data missing in the log. Setting Windows Task manage priorities isn't going to affect the speed of execution.

If you don't need to monitor the system while the application runs you can trigger the application to run through VI Server without the remote desktop.

This links to a community example showing how to run a vi remotely:

https://decibel.ni.com/content/docs/DOC-2146

[RTSLVU]

Instead of remote desktop to monitor and transfer data files why not use the built it LabView web server to monitor and have the program periodically Zip and email the data files.

You might want to try a remote desktop program the is less resource heavy than Microsoft's, for instance one of the VNC derivatives like "Tight VNC".

[Serge67]

Kevin,

Thanks for your reply. 

The Remote Desktop is most likely just one of the processes that I can use to reliably replicate the buffer overrun. I suspect there could be more, possibly scheduled tasks that transfer data to dropbox. My data acquisition app has a shortcut in Windows Startup folder and it starts as soon as Windows boot. It is expected to run continuously 24x7 and we have a watchdog monitoring the data flow. In case anything goes wrong it will reboot PC. 

I think the customer uses Remote Desktop just for a glance at the screen and data graphs to ensure that everything works. The system is in a remote inaccessible location, therefore they can't do it locally, but there is no real need to login with the RDC unless there is an evidence of missing data files. I think it is more like a comfort thing for the customer to be able to confirm the system integrity. The RDC itself doesn't seem to cause trouble if it stays connected for a long time; it is initial connection when initialization and handshaking happen cause a brief buffer overrun.

[Serge67]

Yes, I am considering suggesting to customer VNC as an alternative to Remote Desktop, but the real problem I am trying to resolve is making my data acquisition app executing more deterministically and being immune to Windows attention outages. Remote Desktop just happened to be one of them causing the outage when Windows stops serving time critical thread in my app