Long term analog aquire on USB DAQ

[funkytuqe]

I implemented a producer/consumer strategy but I am still seeing the error.    I even tried removing the statistics calculation and all file operations to scale down the code to just the aquire samples and this also still fails.   I don't think this is a prosessing power problem but rather some kind of connectivity issue with the DAQ.

[crossrulz]

A few comments from the last VI you uploaded:

1) Use arrays and a FOR loop for setting up your channels.  Makes things a lot simpler.

2) There should be no reason to use a "Reinit To Default" for a latched button.

3) Speaking of the button, NEVER have a control or indicator with no label.  You can hide the label if you do not want to see it on the front panel.

4) Since you are doing continuous sampling, do NOT wire up the Samples Per Channel on the DAQmx Timing VI.  This limits your buffer size.  In this case, you limit to 1 second's worth of data.  So if there is any hiccup with your computer (which happens all the time with Windows), you will lickely get the buffer overrun error.

5) The Producer/Consumer will help you.  My recommendation is to just move the logging to the consumer loop.  By offloading this slow process to another loop, you can make sure you get back to reading your DAQ in a timely manner.

6) I would also try to not use the Express VIs.  If for no other reason than to get rid of the Dynamic Data Type (which I despise since it hides important information).  But you can likely do your analysis a little more efficiently than how the express VIs tend to do it.

[crossrulz]

And I finally found a good post for what I initially thought the problem was.  The summary is that Windows 7 introduced a power saving "feature" in that it will randomly turn off the USB bus that your DAQ is on.  I am not sure if this will cause the buffer overflow error or some other error.  But here is a link to show how to turn this "feature" off (quick summary: go into Device Manager and set the USB hubs to not turn off).

http://forums.ni.com/t5/LabVIEW/Problems-With-USB-to-Serial-Adapter/m-p/1541002#M570924

[Blokk]

You can read my journey (from 2013) with a USB-6009 device, we had the same error code what you get: http://forums.ni.com/t5/LabVIEW/USB-6009-USB-port-bug/m-p/2436194

I have no idea if this is your actual problem, but you can give it a try.

Read the post through. The suggested workaround (with that property node value change) only gave us a "half-solution". The main source of the problem was that we used an USB port on our laptop which had a hub internally (common thing with laptops). The final solution was to avoid using these USB ports on this laptop, and we used the "blue" USB3.0 sockets. Looks like these sockets were directly connected, and not via a shared hub inside the laptop.

Later on I got an advice from an NI engineer: "If you want the most stable USB-DAQ communication, do not use a laptop, but a PC with a brand/quality PCI-to-USB interface".

edit: so to summerise --> Do not use USB hubs! Double check what USB port you use if you have a laptop (even internal hubs are used sometimes in case of desktop PCs). Do not use such ports! Best is a dedicated PCI-to-USB interface...

[mcduff]

I cannot see your VI as I have an older version of LabVIEW, but here is some advice that may be helpful.

1. Look at the Voltage - Continous Input example VI. It is under help and find examples.
2. Log your data in TDMS, like in the example, and convert afterwards to a different format if needed.
3. Set your number of samples to be an integer multiple of the disk sector size, this trick adds great stability.

Cheers,

mcduff

[funkytuqe]

Thank you all.  It appears as though i have multiple issues contributing to the error.  As of now the application is much more stable and i will continue to improve it through manual parallel data operations rather than using the express VI.  For now not wiring the samples per channel and double checking the USB port power options for the most part is working.