executable crashes (error -200279) but running via visual studio it's fine!?

[chicago_joe]

Hi,

  i'm working on a fairly simple continuous acquisition program with a bug that's very mysterious to me. 

Basically,  if the application is slowed down sufficiently (either by running thru VS,  or by opening a bunch of other programs),  then everything is fine.

but if i run the executable in bin/debug i eventually get a crash (sometimes),  and if i run the executable in bin/release i almost always see it crash. 

here is the full error message:

---------------------------
oh shit. your experiment is RUINED
---------------------------
Measurements: Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten.

Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem.

Property: NationalInstruments.DAQmx.DaqStream.ReadRelativeTo
Corresponding Value: NationalInstruments.DAQmx.ReadRelativeTo.CurrentReadPosition

Property: NationalInstruments.DAQmx.DaqStream.ReadOffset
Corresponding Value:


Task Name: inputTask

Status Code: -200279

   at NationalInstruments.DAQmx.Internal.AnalogMultiChannelWaveformGenericReadAsyncResult.End()

   at NationalInstruments.DAQmx.Internal.AnalogMultiChannelReaderImpl.EndReadWaveformGeneric(IAsyncResult asyncResult)

   at NationalInstruments.DAQmx.AnalogMultiChannelReader.EndReadWaveform(IAsyncResult asyncResult)

   at MacLab.Daq.aicallback(IAsyncResult iar) in C:\Documents and Settings\Jason MacLean\My Documents\Visual Studio 2008\Projects\DemonfireBehar\DemonfireBehar\daq.cs:line 346
---------------------------
OK  
---------------------------

and here is the function that's crashing: 

(the way this is set up is that a continous output task is running, and a continous input task is running.  i perform asynchronous memory optimized reads to get the data from the input buffer.   i buffer internally,  so that there are N=numWaves  different  arrays of AnalogWaveforms that are passed to the NI function.

after i get each waveform,  i write it directly to harddrive in raw, unprocessed format. 

  /// this is the callback that we register with NI for every buffer read during continuous acquisition.
        /// </summary>
        /// <param name="iar"></param>
        protected void aicallback(IAsyncResult iar)
        {
            try
            {
                AnalogWaveform<double>[] data = reader.EndReadWaveform(iar);
                this.counter++;
                int currentWave = counter % numWaves;

                if (System.DateTime.Now < this.endTime && this.keepRunning) //tasks can have a specified end time, or we can end via keepRunning, which can be set by other functions or the UI (programmatically or interactively)
                {
                    System.Threading.Thread.Sleep(100);
                    this.reader.BeginMemoryOptimizedReadWaveform(-1, this.inputCallback, null, this.dataBuffer[currentWave]);                    this.writeData(data); //send the data straight to disk (as raw binary)
                }
                else
                {
                    this.writeData(data);
                    this.doneAcquiring();
                }
            }
            catch (Exception e)
            {
                Scan.safetyShutterClose();
                System.Windows.Forms.MessageBox.Show(e.Message + "\n\n" + e.StackTrace, "oh shit. your experiment is RUINED");
                System.Windows.Forms.MessageBox.Show("the application will exit when you click ok", "crashes: 1  . you: 0");
                System.Windows.Forms.Application.Exit();
            }

        }

i'm really confused why i need to slow this application down in order to have it run properly!  suggestions and observations are appreciated! 

[ManLongAtNI]

Hi chicago_joe,

As the error implies that your DAQmx read hasn't read fast enough before the data was overwritten. It may be attributed to the time its taking for you write the data elsewhere. FOr more information on this error reference the following KnowledgeBase article Why Do I Get Error -200279 from my DAQmx Read VI or Property Node?

Regards,

Glenn

[chicago_joe]

Glenn,

thanks for your reply,  but what's confusing me is that the fix in practice is to slow the code down,  either by running it within visual studio or by increasing the time passed to  the sleep()  command.   So how is it that the error implies i'm going to slowly,  but the solution implies that i'm going too quickly? 

as a sort of check on this -  i pass rather large buffers to DAQmx, and they come back typically about 3% full (250-400 samples in a10,000 sample buffer).  so i don't think i'm polling the device too infrequently. 

[ManLongAtNI]

chicago_joe,

I'm not clear on which aspect of your program should be 'slowed' down or 'sped' up. The error implies that the read is not happening as quickly before the buffer gets new data. You may need to evaluate which of the proposed fixes on the KnowledgeBase article would be suitable for your application. 

Regards,

Glenn

[chicago_joe]

ok,  so then,  how is it possible that running in visual studio OR running WITH increased sleep() time speeds up execution versus a compiled executable with no debug hooks and no sleep commands?

[ManLongAtNI]

I wouldn't go as far as seeing one program executing faster than the other rather the 'visual studio or running increased sleep() time speeds' could delay the values being written to the buffer as supposed to the EXE that passes through the code quicker and could result in that error. I suspect that you're running on a Windows OS. Windows is a non-deterministic OS, meaning you can't really know when the OS processes one command to the other. 

Glenn

[chicago_joe]

 i apologize; i spoke incorrectly.  

we are in fact running on windows,  and i agree - we have no idea what windows is doing.

so i think we both agree, though,  that something gets slowed down  via studio or sleep(),   and i'm still confused:  if the (bad, not entirely reliable) solution is to slow things down,  then what's the better solution?    i can verify that i don't need larger buffers, and it seems that i don't need to speed up my executable.  would a faster hard-drive help?  (the write method just literally puts each double value into a filestream buffer).  

relatedly,  my coworker (who is not a programmer)  has come up with the solution of regulating the speed of the code by opening up 10-20 web browsers. my guess is that the windows time-sharing algorithm for the cpu still does a context switch for each browser, and , again, that the key

here is that something is getting slowed down.

you suggest that the values get written to the buffer more slowly,  and here's part of what i don't understand .. :  what happens on the NI board (which has its own buffer, independent of windows) and what things wind up mediated by the OS ?         another thing that's unclear to me from the documentation:  what's the difference between using the continuous acquisition functions versus the finite acquisition?  would i lose data if i did finite acquisition but managed to poll fast enough that the board's buffer was never full?  i'm using the continuous acquisition functions exactly because of the non-determinism of windows- if i don't know when my callback is going to run, i figured i'd better just ask for as much data at a time as i could get. but maybe that's part of the problem?      

[ManLongAtNI]

Can you provide a screenshot of your code, we may be able to find something to better streamline the code

Glenn