Questions on huge finite samples but continuous reading

[David_Lin]

Hi,

I am using PCI 6251, DAQmx, and Visual C++ to do analog sampling.

I have to sample an analog channel for a finite number of data, but the number could be huge. So instead of waiting for all the data to be ready to process, I would like to read a fixed number of data available in the buffer and process first, then read the next batch, process, then the next. The key point here is not to lose any data. Could anyone please provide some sample code?

Thanks a lot!

David

[rpursley8]

Take a look at this.

Set up the task to read the total and then set the sample interval to whatever size you want.  But whatever work you need to do on the data in the bottom loop where the graph indicator is located.

[David_Lin]

I only have Labview 8.2, so I can't open the file. Would you please save it with 8.2 format?

I am more concerned about the procedure to do such kind of task, so it's better I give an example to make my question clear.

If I need to sample an analog input for 15 seconds, I can set up an task like this

 DAQmxErrChk (DAQmxCreateTask("",&taskHandle));
 DAQmxErrChk (DAQmxCreateAIVoltageChan(taskHandle,chan,"",DAQmx_Val_Cfg_Default,min,max,DAQmx_Val_Volts,NULL));
 DAQmxErrChk (DAQmxCfgSampClkTiming(taskHandle,"",rate,DAQmx_Val_Rising,DAQmx_Val_FiniteSamps,samplesPerChan));

Here, the samplesPerChan = rate*15. After I start the task, I may want to read 0.5 sec data a time, which means after I read 30 times, all the 15 sec data should be read without missing any of them. So I may use

for(int i=0;i<30;i++) {

DAQmxErrChk(DAQmxReadAnalogF64(taskHandle,datanum,timeout,DAQmx_Val_GroupByChannel,data,bufferSize,read,NULL));

// do some processing

//plotting

}

here datanum = rate*0.5. Is my way correct? After I read 0.5 sec data, will the available data read with DAQmxGetReadAvailSampPerChan be changed to zero or close to zero? Do I need to set ReadRelativeTo or offset?

Thanks a lot for your help.

Message Edited by David_Lin on 03-10-2008 03:57 AM

[RobertoBozzolo]

Yes, your way is correct. I can add some tips for you to consider: if you acquire samples ordered by scan number instead of channel you can append your data to the array as far as they are acquired and have an homogeneus array after the task completes for further data management. From this array individual channel measures can be extracted by using Decimate () function to take 1 measure every n -where n is the number of channels acquired.

Here a sample of how I used to handle a similar task:

int   slice;     // This is the amount of data I want to handle at a time during acquisition

int   cnt = 0;   // Amount of data already acquired

int   aSize;     // Array size for data acquisition (depends on acquisition time and rate)

int   sRead;     // Samples read on every iteration

double   *mis = NULL;     // The array of measures

// Dynamic array dimensioning must go here

 do {
  ProcessSystemEvents ();

  DAQmxChk (DAQmxIsTaskDone (task, &done));

  // Monitor acquisition
  DAQmxChk (DAQmxGetReadAttribute (task, DAQmx_Read_AvailSampPerChan, &samp, 0));
  if (samp >= slice) {
   DAQmxChk (DAQmxReadAnalogF64 (task, slice, 0, DAQmx_Val_GroupByScanNumber, mis + cnt * numChannels, (aSize  - cnt) * numChannels, &sRead, 0));
   cnt += sRead;
 } while (!done);

// Clear the task

// Extract first channel measures from global array

   Decimate (mis, cnt * numChannels, numChannels, 0, array1);

As you see, I like better to have no timeout on the read function and read only when an enough number of samples if ready. This is to prevent locking on a read function that can prevent me from handling other situations (daqmx or program errors, digital alarms, user pressing abort button and so on).

This examples is in CVI: you may need to adapt it to C++.

[David_Lin]

Hi, Roberto,

Thank you very much! Your info is very helpful and I believe I can use part of it in my code. Just to confirm one thing. Is it correct to set RelativeTo property to DAQmx_Val_CurrReadPos and set OffSet to zero?

But I think you code may have a little problem. If ProcessSystemEvents()takes too much time and the task is finished when you return from it, you may leave some data unread in the buffer. Am I right? Anyway, I understand you point and thanks again for your tips.

David

[RobertoBozzolo]

David,

you're right regarding the read attributes. Loosing some data should be an issue only in case you set RelativeTo property to DAQmx_Val_MostRecentSamp: in this case a "long" activity executed on ProcessSystemEvents may lead you to loose some data; to completely prevent this to happen (while keeping that attribute to DAQmx_Val_CurrReadPos), you may want to increase the buffer size using DAQmxCfgInputBuffer to increase it thus preventing a "loose data" error.

Rearging processing of system events, this is necessary in my application since I want the user to be able to stop the test via Esc or return key, more intuitive than the usual red push button (which indeed is also present! 😞 I have tailored the application so that no other user actions can happen and no other tasks are active at this time but I understand your warning and you can cut from the code if you don't need it. In this case, nevertheless, I would suggest you add a simple ProcessDrawEvents () to guarantee your graph is updated regularly.

Message Edited by Roberto Bozzolo on 03-10-2008 11:06 AM

[David_Lin]

Hi, Roberto,

I appreciate your explanation. It does help a lot. Thanks!

David

[RobertoBozzolo]

You're welcome!

[rpursley8]

Here is my example in 8.2


Message Edited by rpursley8 on 03-10-2008 09:03 AM

[David_Lin]

Hi, Randall

Thank you for the vi. It now works well.

David