exception on second analog waveform read

[drury]

I have this code:

private static void MonitorCallback(IAsyncResult result)
{

        var data = m_monitorReader.EndReadWaveform(result);
        //process data
        Thread.Sleep(TimeSpan.FromMilliseconds(500));
        m_monitorReader.BeginReadWaveform((int) m_monitor.Timing.SamplesPerChannel, MonitorCallback, null);
}

It works for the first callback, but the second the second callback always gives me this error:

    Error=-200278
        Message=
        Attempted to read a sample beyond the final sample acquired.
        The acquisition has stopped, therefore the sample specified by
        the combination of position and offset will never be available.
        
        Specify a position and offset which selects a sample up to, but
        not beyond, the final sample acquired. The final sample acquired
        can be determined by querying the total samples acquired after an
        acquisition has stopped.
        
        nAttempted to Read Sample: 4167
        Property: NationalInstruments.DAQmx.DaqStream.ReadRelativeTo
        Corresponding Value: NationalInstruments.DAQmx.ReadRelativeTo.CurrentReadPosition
        Property: NationalInstruments.DAQmx.DaqStream.ReadOffset
        Corresponding Value: 0

}

For this case, the waveform sample count was 4167, but the error happens no matter what the sample count is.  I have tried it with and without memory optimized waveforms, with and without SynchronizeCallbacks enabled, and with delays of several seconds between end and beginning of the readWaveform calls.  The only thing that helps is stopping and restarting the the main waveform monitoring task after the call to EndReadWaveform() and before the call to BeginReadWaveform().  The problem with that is that it takes far too much time.

What am I doing wrong?
   

[drury]

After looking at the error message, I think the problem may be related to the fact that I am trying to get a finite buffer process it, wait a bit and then repeat.  I have the task's sample clock set up for FiniteSamples.  So I guess I need a way to retrigger the collection without doing a start and stop.  Any ideas?  ContinuousSamples doesn't work because then I get a message about not keeping up with the hardware.

[Euge_Or_Pat]

Hi Drury,

I think that what you should be doing is running a continuous sample acquisition like so:

500ms callback:

    Start acquisition(task handle)

    aquire data(num samples)

    stop acquisition(task handle)

Only certain hardware supports retriggerable acquisition without doing this.  What hardware are you using?  Here is the whitepaper on retriggerable tasks.  In part 2 it talks about what hardware supports it.

Regards,

Pat

[drury]

I am not understanding the suggestion.  If what you are suggesting is to start the task once in ContinousSample mode, then the problem is the buffer overruns and generates an exception as soon as there is some glitch in the application that keeps it from processing the samples fast enough.  But I do not understand what you mean by a 500ms callback.

[Euge_Or_Pat]

Let me give that another pseudocode another try

configure task for continuous samples

While( aquiring samples){

    Start(task)

    Acquire(number of samples you want) \\this will wait until the samples specified are acquired, unless you set a short timeout

    Stop(task)  \\ This stops the task from acquiring more data so that you can wait without a buffer overflow, but allows for you to start the task again.

    Wait( period of time you want to wait inbetween readings)

}

Clear (task) - this clears the task completely, you will have to reconfigure it if you want to restart the task.

I can also post a LabVIEW snippet if that would make it easier.

[drury]

I tried it, and it doesn't seem to fundamentally alter the timing.  It still requires a start and stop which is taking longer than I would like. Conceptually it is not different than operating in finite sample mode with a stop and start after each measurement.

Also due to the bug I mentioned on the other thread that appears to me to be driver related, at one particular setting I get a buffer overflow in continuous mode because it is taking too long to get to the callback.

[Euge_Or_Pat · Accepted solution]

Yeah the stops and starts aren't very efficient so I understand the reluctance to use them. Other than that you have two options:

1. Use a device that supports retriggerable acquisition.  NI xseries devices support this and you can find out more about it here http://www.ni.com/tutorial/5382/en/.

2. have the process continuously acquiring data, and just discard the unnecessary data.  If your wait time between callbacks is small enough that the start and stop is taking too long, this is probably a good solution anyways.

With regards to the callback taking too long, I would make your sample buffer larger and extend the timeout.  http://digital.ni.com/public.nsf/allkb/A224DA0551EEA073862574F60060AB6F