01-04-2013 04:08 PM
Not sure if this was the right board - my errors have occurred a few ways.
I have 17 channels in a task, measuring analog voltages and thermocouples. The task was designed in MAX. Continuous sampling, 10 samples, 100Hz sample rate, 10 second timeout, no trigger, internal clock. By all accounts on http://digital.ni.com/public.nsf/allkb/FEF778AD990D5BD886256DD700770103 I am well within the tolerances of timeout. The DAQ is connected to the PC via ethernet cable. It is not on a network per se - the network cable is direct between PC and DAQ, and the IP address is static.
I wrote a program in Measurement Studio 2010 (using Visual C# 2008 Professional). I used the sample code from NI to set up the asynchronous reads (copy and paste). I'm using BeginMemoryOptimizedReadWaveform as per the example.
My test has to run for 5 hours continuously to monitor a unit in operation. Too often, I get this -200284 error. Unfortunately, this causes me to have to exit the program because I haven't figured out how to gracefully handle it and restart the task (even through exception handling). That means I have to start my 5 hour test over again - not a good thing, especially when it happens sporadically, and often within 5 hours. Sometimes, it doesn't happen for two days.
I thought something in my code was causing it, but when troubleshooting in MAX, it also threw that error - ONCE, but it did.
There is no reason it should be timing out or not having enough samples in a task with a 10s timeout, when it should collect the required number of samples in 0.1s.
Unfortunately, there is nothing I can do to duplicate the error.
A few moments ago, I used MAX to try to duplicate this error with a virtual DAQ. I could easily trigger it at 101 samples, 100Hz sample rate, and a timeout of 1s - it triggered every time I ran the task. However, at 99 samples, 100Hz sample rate, and a timeout of 1s (very close to the timeout threshold) it ran for 15 minutes before stopping due to a -200284 error.
What can I do to avoid this fault from occurring? If there's nothing that can be done, how I can I code my program in Measurement Studio to gracefully restart the task with no user input? (Nobody sits and watches this thing for 5 hours straight; it would be worse than watching grass grow.)
Actual DAQ setup and read code:
Setup Code:
public bool connectDevice() { try { this._continuousTask = DaqSystem.Local.LoadTask(_taskName); this._continuousTask.Control(TaskAction.Verify); this._runningTask = this._continuousTask; this._daqChannelReader = new AnalogMultiChannelReader(this._continuousTask.Stream); this._callback = new AsyncCallback(ReadCallBack); this._daqChannelReader.SynchronizeCallbacks = true; this._daqChannelReader.BeginReadWaveform(Convert.ToInt32(_continuousTask.Timing.SamplesPerChannel), _callback, _continuousTask); OnConnectionChanged(new ConnectionEventArgs(true, "")); return true; }
Read code:
private void ReadCallBack(IAsyncResult ar) { try { try { _data = _daqChannelReader.EndReadWaveform(ar); OnDataRead(DeviceDataEventArgs.DataFromDevice(this)); if (_runningTask == ar.AsyncState) { { _daqChannelReader.BeginMemoryOptimizedReadWaveform(Convert.ToInt32(_continuousTask.Timing.SamplesPerChannel), _callback, _continuousTask, _data); } } } catch (DaqException ex) { #if(DEBUG) Console.WriteLine("E: " + System.DateTime.Now.ToString() + " - DAQ Read Error - " + ex.Message); Console.WriteLine(" - attempting to hold connection open during read failure"); #endif // _continuousTask.Dispose(); // OnConnectionChanged(new ConnectionEventArgs(false, "")); // _runningTask = null; } } catch { // Catches object disposal exceptions } }
The task disposal was in the sample code; it's commented out to try to keep it open since disposing it still didn't allow me to restart the task in code. The outer try-catch is to keep from throwing an error when the program is closing and the task is still running; it doesn't prevent -200284 from occurring.
I'll try any suggestions... thanks in advance!
01-07-2013 03:08 PM
Uncommenting the task close code and calling the task start code (connectDevice()) from the exception allowed this to at least resume the testing. Unfortunately, it does allow for breaks in the data.
I also found that the timeout settings in the task in MAX did not flow through to the C# code. I had to add a line in connectDevice to manually set the timeout to 1s. It was set to 10s even though the MAX task was set to 1s.
The line I added was:
this._continuousTask.Stream.Timeout = 1000;
I then choked the MAX task at 100 samples, 100Hz read rate (1s read at optimal using a virtual DAQ). With the 1000ms timeout set as above, it would fail 80% of the time, but close the task and retry after failure over and over again successfully.
There is still no reason why I would get timeouts after 10s when running 10 samples at a 100Hz sample rate. This hack makes the test program usable, but still not optimal.
01-07-2013 04:22 PM
Hello,
Adjusting the timeout would be one work around. This article steps through 7 different troubleshooting alternatives to adjust for this error.
What hardware are you currently using?
Why Do I Get Error -200284 from my DAQmx Read VI?
01-08-2013 07:53 AM
Hi M. Whitaker,
The timeout was actually reduced from 10s to 1s. As mentioned in the first post, I am running continuous sampling, 10 samples, 100 Hz sample rate. I should have all data within 0.1s.
Why I was geting -200284 errors with the timeout set to 10 seconds is unclear.
I've read that article a few times. For those 7 steps:
Hardware:
This issue appears to be related to either a hardware problem or a driver problem. My timeout was 100x longer than it should take to get a sample. I actually *reduced* it in order to miss fewer samples when it decides to have this glitch. My workaround is to set the timeout to 1s, and if the task fails, stop and then quickly restart the task - all from the asychronous read error handler. I miss some samples that way, but I'm in a position to do so without severely affecting my test. (I'm testing HVAC equipment; pressures and temperatures don't rise or fall very fast.) It's not my preferred fix, though; I'd rather know why it's glitching. If I someday have to perform critical tests with high sample rates for some duration, I want to be able to rely on this equipment.
01-08-2013 03:35 PM
Another option would be to set your Timeout state to be -1, theresfore not setting a timeout limit. When you run this test, do you see any missing samples or data?
What are the A/D Converter modules reading?
01-08-2013 03:50 PM
Hello again and thanks for following up.
When I can get some time on the equipment, I will try to set the Timeout state to -1. However, I'm concerned. If my sample is supposed to occur within 0.1s, and it is timing out at 10s, how much more time will it need? What will happen if the samples never come?
The higher accuracy A/D converter is reading four voltage-output pressure sensors. Output for each is 1-5V for 0-5MPa (hence the higher accuracy requirements; I originally had two of the less-accurate converters. Power supply to the sensors is 24VDC, the frame of which is grounded and also connected to the DAQ. The timeout errors occurred without that grounding connection as well.
The other A/D converter is currently not connected to anything. I don't have another blank cover, though, so I left both it and the digital I/O in but unused. They are not in the task, either. I do plan to implement some additional analog inputs and digital I/O in the future.
Jim
01-11-2013 02:21 PM
Hello Jim,
I am working with the other Applications Engineer that is working on a similar thread. There are a few things that will help us to test and understand the error a little bit better.
What drivers and software versions are you using?
Will you please post your code, and a NI I/O Trace of your code producing the error.
01-11-2013 02:56 PM
Hi M. Whitaker,
I'm participating on that thread. I have the DAQmx Windows software installed and am using Measurement Studio on Visual Studio 2008 Professional. MAX reports that the version is 5.3.1f0. I know there is an update available; however:
If the changelog suggests that this issue goes away in the latest version, I will start the update process tonight.
I saw that Chris had mentioned the I/O Trace on the other thread. I need to investigate how to set this up on the test machine, hopefully without affecting the testing. As the system is now used in production and I only have one DAQ, I usually can't bench test it. Might take a week or two for me to get a trace for you, but I certainly will do so.
The full software is quite large and involved, but the DAQ code is small and self-contained. I attached the full file to this link. Since most of it copied from the sample asynchronous read code, it should be fairly easy to understand, but I'd be happy to explain any of it that is unclear.
Thanks again for your help!
Jim
01-14-2013 12:31 PM
Hello Jim,
In order to set up an NI I/O check out this link: http://digital.ni.com/public.nsf/allkb/282C5D41E2BA04F2862574BA007803B9?OpenDocument
An upgrade isn't needed, but it also shouldn't cause any instillation problems with Measurement Studio. We are just trying to get all the information necessary to recreate the system to test.
What version of DAQmx are you currently using? You can see that in MAX under the Software tab.
01-14-2013 01:10 PM
Hello again, and thanks for following up.
For some reason the upgrades cause Measurement Studio to replace a file, which is built against (or references) a MSM file that has a different key. I'm not that worried about this issue, though.
From the development PC MAX output:
NI-DAQmx Device Driver 9.5.5 - version 9.5.5f4
NI-DAQmx MAX Configuration 9.5.5 - version 9.5.5
NI System Configuration 5.3 - version 5.3.0f0
Measurement Studio for VS2008 - NationalInstruments.DAQmx - version 9.5.35.112
Measurement Studio for VS2008 - Common - version 12.0.35.253
I am 98% sure the testing PC has the same versions. I had to upgrade both at the same time. After upgrading the development PC and pointing the code toward the new libraries, the output binary no longer ran on the testing PC (which makes perfect sense).
I see that the latest DAQmx version is 9.6.1.
I build the software with Visual Studio forcing the binary file to 32-bit architecture. My development computer is Windows 7 32-bit, and the testing computer is Windows XP SP3 32-bit.
Later this week, I hope to run an I/O trace. Unfortunately, I am traveling early this week.