Error 200284 keep showing up with DAQmx/USB6259

[BryanL]

This error of 200284 has been persistantly showing up in my high speed data acqusition using DAQmx Read with USB6259 running LV8.5.1 and DAQmx 8.7.1.  I tried most of the approaches discussed on this forrum regarding this error such as increasing time out and sample rate, but still getting it. I stripped down the application that I recently took over and attached the basic vi..please voice any suggestions, thoughts, solutions, and comments, I really would like to see this code work out as it is our basic stuff.  many thanks in advance. 

A little more detail...the original code (and this striped down version) would run for a minute or so with the loop index getting to over 20k, or 40k..but most likely stop before 60k with unpredictable numbers...thanks again for taking a look at the vi.

Bryan 

Message Edited by BryanL on 02-15-2009 02:26 PM

[TCPlomp]

There is some race condition in you init. routine. Let me try to explain (and understand):

Your Input task uses the Output clock

Your Output task waits on the Input start trigger

This might cause what you see. I would make one master task (Input), let Output use the Input clock and let Output start on the Input start trigger.

Now first start Output and then Input.

What is quite strange is that you only write data once.

Ton

[BryanL]

Thanks Ton for pointing out the race condition, as I just took over this code two days ago and havnt done much analysis on it..but the problem seems to be caused by the DAQmx Read in the while loop though. The DAQmx write on the output was to trigger a source which generally only need to run once and worked everytime.  I had no problem starting the data acquisition and getting the expected waveform read out, but only cannot run with extended time.   I have played with adding delays to the while loop and was not solving the problem..

Bryan

[Doug_L._Bear]

Something that I noticed is that your sample clock is using the Analog Out Sample Clock but all of your tasks are analog input.  This could be causing some issues, as the analog output clock should never start with no analog output happening.  Hope this helps.

Doug F

Applications Engineer

National Instruments

Message Edited by Doug L. Bear on 02-16-2009 04:53 PM

[BryanL]

Hi Doug,

Thank you so much for looking into this problem...this has been a real show stopper as the problem is very unpredictable. The code would run on another machinge for hours but a minute on the current one I want to use.

I may not have explained my task setup, what we were doing is to use the input device to read a detector and the output to run a light source, this process is expected to run many hours or days.  In the input task train, a trigger was set to start the waveform (generated from a separated VI) on the output device to synchronize data acquisition.  After this triggering event, the output device runs contineously and the detector was read by the input also contineousely with the while loop. Everytime I started the code, the task always starts OK and with expected data being read...the problem is it would not run extended time.   

Based on your comments I tried to wire the error cluster to the output chain first then to the input chain from after the output timing VI, this shall address the concern of using the output clock before output started...but the problem still come up as before.

What I noticed is that the current read position will keep increasing...dont know if this is expected behavior? Thanks for more help on this.

Bryan 

[BryanL]

Also the code worked ok with the PCI card before, but kept having error 200284 after switched to USB and the two laptops we had problems are both USB2.0 based.  Another issue observed was that at the Windows (XP) start up, a message of "National Instruments variable engine has stopped working...". dont know if anyone has seen similar problems or have a related diagnostics?

Bryan

[Doug_L._Bear]

Bryan,

I think the broken shared variable engine definently sounds bad, which firewall/anitvirus software are you using, as we have some known issues with certain software types.  I would attempt to restart the shared variable engine by going to the Control Panel»Adminitrative Tools»Servicesand right clicking on NI Shared Variables and selecting restart.

The reason this error occurs is when there is no data to read in, which could happen if your waveform never begins exporting or if it ends exporting and you are still looking for data.  So I guess the next step would be to ensure that the there is still data available to read in.

Doug

[BryanL]

Hi Doug,

First thank you so much for the help and support.  I went to restart the NI variable engine and disabled the ZoneAlarm and firmwall, the variable engin now runs and not stopped, but the VI still stopps with the error 200284. Anythings else you think might be the issue here?  I really need to get this thing working as I have been on it for a few days now...please help.  Thanks again.  I have also copy and paste my post and that of Dansch here to give more background info:

Hi Dansch,

Thank you for looking into this issue!  I have compiled a reply to your comments and questions in the following quoted message: 

dansch wrote:

Hi Bryan,

I took a look at your code, and after modifying the analog output channel, I was able to run it fine for a very long time on a PCI-6251 board without any errors.

--------------------------------------------------

Our original code also runs ok with our PCI boards, only after we switch to USB then we have this problem of error 200284 stopping the acquisition. The code also runs ok on one laptop with older USB (XP service pack 1), the two laptops with newer USB2.0 always have problems with error 200284 on one and 200279 on the other(XP Service Pack 3).  I am trying to get the one with 200284 to work.

One thing that I am interested in is the analog output task that you are referencing, since I am unable to see what type of setup you have configured for this channel. I am interested in knowing why the analog input task is using the ao/sampleclock as the source for its sample clock rather than the other way around (ao channel using the ai/sampleclock).

--------------------------------------------------

The was not clear about the logic of the triggering setup of the initialization step, however, the analog output task used the task input setup from MAX, this also triggers the timing on the analog input.  The output chain is for running a light source with a wave form generated by a separated VI using the waveform parameters as shown on the front panel of my attached SampleVI.  This source runs continuesouly with the same waveform  function.  The input chain reads a detector contineously as DAQmx Read was put into the while loop. The start of the output waveform was triggered by the input chain so that the light source and data acquisition are synchronized.   We never had problem to start the data acquisition as we always read the correct waveform back.  The error seem to alway came from the DAQmx Read function in the while loop as the code on the left side of the while loop onlys runs once, while the while loop will keeping running, until it stops a minute or so later by the error 200284.

Usually, when this type of -200284 error occurs, it is due to a problem with not receiving a trigger or sample clock edges. Perhaps something is happening to the analog output task that is affecting the analog input channel since it is using the ao/sampleclock.

 ------------------------------------------

I will check further on the output task setup in MAX..if this is the issue, what is the recommended setup for the output task? 

A couple of other things I would like to know more about are why you are reading just a single sample each loop iteration and also what your application involves since I noticed the program samples numerous times on the first channel for each single sample on the others. What overall rate are you trying to accomplish as well? Please let me know if you have any additional insight into your application. Regards,

-----------------------------------------

I was only reading a single sample for the demo purpose as it generates similar error as in the original application where we read all channels. The first channel is where the detector response are read and are accessed at the highest frequency.  That is why we build 992 instances for this channel and leave the other 8 channels to read some other environmental parameters which happens at a less frequent time. This allows us to keep data acquisition going without restart other tasks. This was recommended by an NI engineer earlier to another enginer here and was work fine. 

The following are some of our input parameters:

On the Outuput side:  Waveform Scan Rate or Frequency (Hz): 1000    Number of Points in Waveform is 1000,  Waveform Update Rate is: 1000000/s, this final rate goes to output timing VI 

On the Input side:      Number of Sample Spectrum (total numb. of channels) 1000.  Number slow channels: 8.   Input sample rate: 1000000(Hz). This rate/1000=1000/s goes to the input timing VI 

Please let me know if you need more info, if you do not mind, could you please send me a number and best time to call?  Many thanks.

Bryan

[BryanL]

I tried replacing the output timing source of Dev2/ao/OnboardClock with Dev2/ai/SampleClock and didnt connect a source for input timing, the VI runs without time out but the waveform read was not what I expected from the start of the VI.

Then I tried without connecting any source to the timing VI for both input and output chain as in the example of Multi-function Sync AI-AO VI, this time I got the correct waveform read back  at first but when the loop runs to ~35K (another time to ~51K) loop index value, the waveform changed into something not as expected.  This changing point may corresponds to my previous stop point by error 200284. 

If I use the Dev2/ai/SampleClock for the output timeing source, what is the best timing source for the input timing? I would really appreciate your help again to configer the based timing setup. Thanks.

Bryan 

[TCPlomp]

Bryan could you add your VI?

I have some time to test some things today.

Ton