Continuous Acquisition on MSeries error with computational overhead

[R. Fink]

First, thanks for reading this and appologies if it has been answered before.   I looked but was unable to find anything pertinent.

I am having an issue where my board is dropping samples in continuous acquisition if light load is placed on the machine or if some simple computation is being done in the callback.  I have tried tweaking buffer settings and a few other things but I'm not sure where to go next.   I would appreciate help.

Setup:
-NI-DaqMX 7.4
-PCI-6251 M-Series board.
-Managed C++ app using .Net
-Counter timer clocking 3 Digital Out lines with one DO clocking out 2 AO lines and another DO clocking the AI.
-Computer: 2 GHz P4, windows XP, 512 MB

Attempted Operation:
-Continuous acq, acquiring sample blocks of 684,288 samples (representing an image).  Samples acquired at 1 MS.
-There is some initial delay each cycle so the callback is being hit about once a second.
-In the callback:
// Collect Data
dDataArray = analogInReader->EndReadMultiSample( ar );
// Process data
doProcessing( dDataArray );
// Restart
analogInReader->BeginReadMultiSample(dSamplesPerChannel, pAsynchCallback_analogInCallback, 0);
-the processing writes the data out to a file.

Problem:
-Sending a known pattern of samples via a function generator the operation is dropping samples.  If more of a load is placed on the machine more samples will be dropped.
-In my experience with previous NI cards the continuous AI operation was always reading samples into a buffer at a fixed rate.  The callback would pull blocks out of this buffer but the read was always going on.  I am uncertain what is going on presently that is causing the continuous acq to miss samples.

I am happy to post any further information but I wasn't sure what would help convey the problem and what would just be additional clutter.

[Marni]

Dear R. Fink,

Managed C++ .NET is not officially supported or documented for the NI-DAQmx driver, so it is understandable that you are running into some frustrations in trying to use it. If you would be open to using C# .NET you could easily find many examples and documentation for the functions, but for the timebeing we can only offer support for unmanaged C++ .NET.

For unmanaged C++ code you may be interested to check out the ANSI C examples provided in the "C:\Program Files\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Analog In\Measure Voltage" folder of your hard drive. Continuous acquisition examples for NI-DAQmx can be found here. If you need managed examples you should look at the C#.NET examples in the "C:\Program Files\National Instruments\MeasurementStudioVS2003\DotNET\Examples\DAQmx\Analog In\Measure Voltage" folder of your local drive.

Have a great day!

Marni S.

[R. Fink]

Well, I used the examples and documentation available for C# in writing the MC++ example.  I'm currently in the process of translating the particular section from MC++ to C#, but I don't think it'll have any effect on my problem as the IL produced by both should be approximately the same.  We shall see though.

My more pressing concern is that the CPU load from just running the board and without doing anything with the collections is between 88 and 99 %.  I suspect this is at the heart of the problem.  At present, it seems more likely that the board is for some reason maxing out the reasources of the 2.8 GHZ p4 (somehow) and that any perturbation is causing it to fault.

[Marni]

Dear R. Fink,

To lower the CPU usage while reading, set the wait mode on the read to sleep. When the Wait Mode is set to Sleep and a read operation needs to wait, NI-DAQmx tells the operating system to put the read process to sleep for some minimum period of time. The default value for the sleep time is 1 millisecond, but this value can be changed through the Sleep Time property on the DAQmx Read property node. While the process is sleeping, the operating system does not schedule it to use any of the CPU. As soon as the sleep time has expired, NI-DAQmx checks to see if the waiting condition has been met. If the read process is reading a lot of data that is arriving very slowly, then this wait mode vastly reduces the CPU used by the process at the expense of possibly longer latencies caused by putting the process to sleep. However, it should be noted that if data is arriving or space is being made available fast enough such that the NI-DAQmx process does not have to wait for data, then the process will never be put to sleep and no reduction of CPU usage will occur. The function is as follows:

DAQmxSetReadWaitMode(taskHandle, DAQmx_Val_Sleep);

Have a great day!

Marni S.