Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

I am getting 200284 and 200279 errors on one of of 20 identical software stands. Overseas on a install and I need to solve this quickly!

I have a software solution that is used in over 20 different installations.  It is written in .NET and uses continuous sampling with an asynchronous callback reader to read 100S/ch and 1000S/ch/s.  The next call for samples will not fire until the last is complete.  I am using one USB cDAQ chassis and one ENET (9188) chassis.  I have used these devices extensively on other systems.  I am installing two nearly identical systems and one seems to throw a 200284 error every 30 minutes or so (random). I swapped out the network cable to see if that was the problem, yet the problem persists.

Typically, when this happens the device will fail a self test and I have to go through a series of restarts/reboots to establish connection again.  The power is connected to an automotive 12V battery with a 60A supply for charging purposes, so power should be consistent.  I did a wiggle test and it passed.  There are other devices on the same power that do not glitch (engine ECU, etc.).  I have five days left here and I must solve this problem ASAP.

If I disconnect the power supply, the failure mode is the same. 

 

Is it possible to recover from this without killing and restarting the task?

 

  1. Create a task.
  2. Add channels to the task.
  3. Create the reader
  4. Start the reader
  5. Reader fails due to timeout
  6. ??? Recovery ???

 

Any help would be greatly appreciated.

Thanks.

Programming Data Acquisition and Control in Measurement Studio and Labwindows/CVI
0 Kudos
Message 1 of 2
(1,353 Views)

Hey Michael!

 

This is a very interesting issue. So the VI project that you are using is the same throughout all of these systems?

You say that only one of the two systems is throwing this error. Is there a way that we can swap the hardware between systems (and leave the software unchanged between the two) and verify if the problem follows the hardware to the other, previously working, system?

 

Generally when these errors occur, a producer/consumer architecture is the best way to solve it. Also, we have knowledgebase articles that cover errors 200284 and 200279 that will be helpful tools for you as well.

 

You should be able to recover from an error like this by simply restarting the device rather than the controlling PC. There is an option for this in Measurement & Automation Explorer, but there is also a DAQmx function called "DAQmx Reset Device.vi" found in the DAQmx Device Configuration Palette. If this reset reestablishes the connection properly, you can programmatically run this VI whenever the errors occur.

The only issue with this is that you will need to restart the task because after resetting the device, the configuration that the task established is cleared.

 

I hope this helps! Have a great day!

Peter E
Applications Engineer
National Instruments
0 Kudos
Message 2 of 2
(1,327 Views)