Long term analog aquire on USB DAQ

[funkytuqe]

Hello, recently we have run into issues with our USB 6009 and USB 6002 DAQ's.    I have written a .vi that sets up 4 analog channel inputs (at 2000samp/sec) to log battery voltage and write statistical data to file.   We have been using this very successfully in the past few years to run battery life tests that can run anywhere from a few days to a few weeks.    More recently we have begun to come across an issue where the data logging stops mid test, this can happen anywhere from an hour or 2-3 days into a test.   During this outage labiew can not seem to see the USB daq, but if I open MAX the device is alive and well.   If I unplug the DAQ from USB and plug it back in the application will pick up and continue to log.    These tests are generally run with an exe and not in the development environment, and we have been using DAQMX15 more recently on the test computers.    The application was developed in Labview 8.6.   I have attached my .vi for reference.   Could there be some discontinuity between older .exe DAQMX vi's and the new versions of DAQMX causing this issue?  or have I done something bad in my .vi and somehow got luck over the past 4 years without failures?

Thanks

[Wolleee]

Hi,

It sounds like you havent changed the vi, nor the hardware. Ive heard of windows updates sometimes causing issues with drivers, but if i had to take a quess it would be compatibility issues.  I dont see labview 8.6 supported by daqmx15 or NI-USB 6002. Possibly try reverting to an older daqmx. If you are going to revert you must first uninstall the latest driver of daqmx, the earlier install will not install over a later version.

daqmx 15

[Bob_Schor]

I agree with Wolleee that, though Drivers are supposed to be (somewhat) "backward-compatible", it is a good idea to have drivers that are within a year or two of the LabVIEW Version used to develop the software.  Your software and driver are almost a decade apart.

Some other thoughts.  Does noone have sufficient LabVIEW experience to avoid the Dreaded DAQ Assistant and its Evil Twin, the Dynamic Data Wire?  You can do a much better (and more transparent) job by coding the acquisition with 3-4 DAQmx functions (read the article you find by web-searching for "Learn 10 Functions in NI-DAQmx").  You can also (probably) do a better job of saving the data by doing more "hands-on" File I/O (in particular, I think the LVM file definition may have changed a bit -- the 2016 Help says it's a Text file, but I saw someone else for whom it appears to create an Excel 97-format .xls file).

Could you problem be that you got "hung-up" in file I/O?  I notice that you are not using a Producer/Consumer pattern, so if file writing gets delayed (such as your Anti-Virus software kicking in and hogging the CPU), things may "go south" as everything is in the same loop.

Bob Schor

[funkytuqe]

Thank you for the replys.    We just purchased a new veriosn of 2016 labview this week so i will install and rebuild this applicaiton on the latest platform, to see if that helps.

Bob, I'm not sure where the test is hanging up so yes i suppose it could be in the file write.   How do you sugest i decouple the file actions from the DAQ functions?   Our other test applicaitons write data in the same way and have not had the same hangup issues which leads me to believe it is a DAQ functionproblem.   I'm always up for making applications more rubust and i understand my coding is probably rather "mickey mouse" in the grand scheme of things

And yes i agree the DAQ assistant is not a very flexible format to build distributibles with, i much prefer the DAQmx functions to build VI's.

[Wolleee]

You can start with the daq examples that ship with labview, that should give you a good idea of where to start.  When you finish you can always post your code and ask for advice.

I dont know your sample rate, but when ive ran battery tests, the sampling rate is somewhat slow, otherwise you would have huge amounts of data.  That leads me to believe its probably not the File IO, but that is still a possible problem. 

Always better to do it right the first time and not have to worry about it.

[p0rter2000]

I had a similar issue where our USB device would stop working mid-test. It ended up that windows was shutting down (putting to sleep) the USB port to save power. Make sure that the setting (check box) in the device manager under the USB port you are using is not checked (Allow the computer to turn off this device to save power).

[funkytuqe]

Thank you everyone for your comments so far.  Here are some updates on the problem.   I have imported and rebuilt the distributable application with LabVIEW 2016 using DAQMX16.1.   I have updated the test machine(s) with DAQMX16.1 and installed the newly built application.   Unfortunately, this did not fix the DAQ dropout problem.   Again I would like to iterate that these NI USB DAQ’s have been a reliable workhorse around here for quite some time and it’s only been in the last 6 months or so that we have been having this problem.

I did a bit of sleuthing and found that the DAQ’s are throwing error 200361 (buffer overflow) and found this thread - http://digital.ni.com/public.nsf/allkb/611475F9BE62881E86256FDC0062B1BB.  I applied the suggested fix with no luck, I turned the sample rate way down to 500samp/sec (from 2000) and still threw the error.    I tried configuring the USB port to turn off auto suspend mode as p0rter suggested, DAQ still dropped out.    I tried multiple quality high power USB hubs to rule out a current supply issue, DAQ still drops out.

My next attempt will be to decouple the data processing and file operations as suggested to see if that helps.   I will need to learn how to run parallel loops in order to do that properly first.

[Wolleee]

Can you provide new code? There could be an underlying issue. I would suggest using a producer consumer loop architecture for your own peace of mind as well. 

Im not sure if this is useful, but have a look at THIS.

This example should help a lot for what youre doing. 

Producer Consumer Example

[funkytuqe]

Thank You Wolleee i will take a look.

See attached latest vi, this is intended to set up 4 Analog inputs in differential mode at 2000 samp/sec each.   Then in a loop output samples to math function to calculate mx/min/avg and write those statistics to file.

[Wolleee]

I would really suggest using a producer consumer architecture.  It is really simple to learn and it will probably speed up your code.  Also get rid of the Express VI's.  They are nice for getting stuff going, but for example your write to measurement file will open, write to file, and close to file everytime you run your loop. Its a waste of resources. Look into THIS for file io usage and impliment that in a producer consumer architecture.  Even if it doesnt fix the problem at least youll free up resources.