Acquire data with DAQmxReadAnalogF64

[chemph]

Hi guys,

I'm aquiring data with DAQmxReadAnalogF64. While aquireing, I display the data in a Strip Chart (I also set the number of data to display that I can influence the displaytime or the speed of graph)
The second value, I want to change is the sample rate. My question is, how the sample rate and the samples per channels are connected.
When I test my programm and set very high sample rates and aquire e.g. 5 seconds, than the data in file are only by 2 seconds. When using smaller sample rates this problem does not appear. If the sample rate is to high, I want to have an error before starting the tast, not after a few seconds.

Greets,
chemph

[Philipp R.]

Dear chemph

The "samples per channel" attribute gives you the buffer size for a input channel (cp. "How Is Buffer Size Determined?" in the DAQmx Help).

To prevent the error with too high sampling rates you can query the maximum sample rate of your device before configuring the task:

DAQmxGetDeviceAttribute ("Dev1", DAQmx_Dev_AI_MaxSingleChanRate, &lMaxSmps, 0);

Best regards

Philipp R.

[chemph]

I'm using the following code:
while ( gRunning )
{
    DAQmxErrChk (DAQmxReadAnalogF64 (taskHandle, -1, 10.0, DAQmx_Val_GroupByScanNumber, data, 5000000*numChannels, &numRead, NULL));
   
    if( numRead>0 )
    {
        PlotStripChart(panel,PANEL_STRIPCHART,data,numRead*2,0,0,VAL_DOUBLE);
       
        for (i=0; i<numRead*2;i++)
        {
            reltime=reltime + (1/rate);
            fprintf(MESS_FILE, "%f;%f;%f %d\n", reltime, data[i], data[i+1], numRead);
            i++;
        }
    }
    ProcessSystemEvents();
}

When I test it with the highest samplerate my Device supports (100000) the aquasation is very slowly. After 10 seconds, the file contains only data to 3 seconds and the strip chart is at the same time. If I remove the fprintf function, everything is right (the strip chart showas the right time). So the problem is in the fprintf function. It is too slowly.

[RobertoBozzolo]

Streaming to disk can be the bottleneck of your process, so if you do not want to keep in memory all your data (but with nowadays PCs you could do it without any real disadvantage even for 5 million samples) you may want to use faster functions than a loop with a lot of fprintf; additionally, the reltime column can be calculated after your acquisition has terminated. You could for example use ArrayToFile to save all data to disk in a single instruction appending data to existing ones; or  fwrite ((char *)&data, sizeof(double) * numRead * numChannels, 1, fileHandle); but in my opinion you should really consider keeping all data in memory and save them after your process has terminated.

[chemph]

Hallo and thanks for your tips!

Before the loop and after it, I set a printf-function. So I saw that the printf-procedure is really slow (At 100000 samples per channel a couple of seconds). But the puffer does NOT overflow. Althougt the measurement is to small. I can't find the mistake, I don't get any error while running the program but with higher samplerates (100000) there is a big time offset.

[Philipp R.]

Dear chemph

You probably shouldn't process system events in your acquisition loop ...

The CVI shipping examples have never exposed any mis-behavior like the one you describe to me. How do these work for you?

Best regards

Philipp R.

[chemph]

Hallo,

I think that I should use process system events because the user schould be able to stop the aquasation by a button. Do you guess that this is the mistake?

Best Regards

[Philipp R.]

Dear chemph

I would definitely get rid of it! Rather use the callback mechanism to stay reactive on the GUI while acquiring data at the same time (cp. example "ContAcq-IntClk.cws"). For maximum performance you should consider doing the data acquisition in a separate thread; again, see the shipping examples to see how multithreading in CVI works.

Best regards

Philipp R.