Error -200284 VI worked perfectly before

[WMICHKML]

I have a VI that previously worked perfectly. It is supposed to continuously take data and record it. After a couple of weeks away, without changing anything, I started getting an Error -200284 (Some or all of the samples requested have not yet been acquired.) Does anyone know why this may be happening. The following is my system information:

National Instruments Software: Version:

CVI Run-Time 13.0.1.201
NI-DAQmx Device Driver 9.5.5f4
NI-DAQmx ADE Support 9.5.5
NI-DAQmx MAX Configuration 9.5.5
NI-488.2 Runtime 14.0.0
NI-488.2 14.0.0
NI Vision 10.0.0
Image Processing and Machine Vision 10.0.0.49152
Services 10.0.0.49152
NI I/O Trace 14.0.0f0
IVI Compliance Package 4.5
LabVIEW 10.0.0
Analog Modulation 4.2.1
Control Design and Simulation Module 10.0.0
Database Connectivity Toolkit 10.0.0
DataFinder Toolkit 10.0.04192
Digital Filter Design 10.0.0
Digital Modulation 4.2.1
Internet Toolkit 10.0.0
MathScript RT Module 10.0.0
Report Generation Toolkit For Microsoft Office 10.0.0
System Identification Toolkit 10.0.0
VI Analyzer Toolkit 10.0.0
LabVIEW Run-Time 2010 SP1 10.0.1
Measurement & Automation Explorer 14.0.0f0
Measurement Studio Visual Studio 2005 Support - See individual versions below.
DotNET
Common 8.9.20.302
Vision 10.0.20.100
Measurement Studio Visual Studio 2008 Support - See individual versions below.
DotNET
Common 8.9.35.302
Common (64-bit) 8.9.35.302
Vision 10.0.35.100
Measurement Studio Visual Studio 2010 Support - See individual versions below.
DotNET
Common 9.1.40.414
Common (64-bit) 9.1.40.414
NI-USI 2.0.0.4901
NI PXI Platform Services Configuration 14.0.0f0
NI PXI Platform Services Runtime 14.0.0f0
NI-PAL Software 14.0.0
LabVIEW SignalExpress 6.0
NI System Configuration 14.0.0f0
NI-VISA 14.0
NIvisaic.exe 14.0.0.49152
NI-VISA Runtime 14.0
Vision Builder AI 4.0.1
LabVIEW Run-Time 2011 SP1 f2 11.0.1
LabVIEW Run-Time 2012 SP1 f9 12.0.1
LabVIEW Run-Time 8.0.1 8.0.1
LabVIEW Run-Time 8.2.1 8.2.1
LabVIEW Run-Time 8.5.1 8.5.1
LabVIEW Run-Time 8.6.1 8.6.1
LabVIEW Run-Time 2009 SP1 9.0.1

I have attached the VI

[.aCe.]

I am not sure how your RFPower task is configured so I am unable to make any sensible suggestion.

Have you had a look at the this link? http://digital.ni.com/public.nsf/allkb/FEF778AD990D5BD886256DD700770103

PS: Use the task out reference on nodes for the following function.

[AKA_TG]

I don't know if this will work for you but I was able to get rid of that error in one of my APPs

by selecting  "hardware timed single point" when initializing the DAQ and then experimenting with data acquisition rate and number of samples (buffer size)

For my system ( collecting a point every 2 secs) I set data rate to 200 pts/sec and buffer size to 2000. ALso I collect all the channels at once and sort things out afterwards.

Hope it helps.

[ben64]

Have you tried putting the Start Task.vi before the loop and the Stop Task.vi after the loop? Starting and stopping a task repeatedly reduces the performance of the application.

Ben64

[WMICHKML]

As a follow on, we took the exact program, and ran it on a different computer, but with the same DAQ. That computer has LabView 14 Professional. It ran just fine without stopping. Then, we plugged it back into our computer and so far for the past half hour, the program has not stopped working. I am thinking maybe there is somthing wrong with the connections. That is all i can think of. Could this possibly happen if the USB 2.0 DAQ were plugged into a USB 3.0 port? 

[JÞB]

Yes a glitch on the USB hub could cause issues-  I'm sure that the FAQ can be dragged out if needed but try a forum search for USB FAQ with my name as poster.

Now that loop,  you have an N Channel N sample read so start it before the loop and pass in the Task on a Shift register.

Read all available samples.  Use some time function to throttle the loop so you are getting chunks at a reasonable rate. and don't stop the task until the loop completes.  Going through all the unnecessary DAQmx State transitions the way you are allmost garuntees that some thing might go bad with a state transition when stopping and starting a conteneous sample Task in a tight loop.  That and branching the Task wire are likely to anger the DAQmx gods.  you seem to have done so.

Keep your loop rate down around 100-200mSec so the vi is responsive to the stop button and the users don't start using the abort.