send DAQ measurement results through serial ports

[le]

Hi, All
I use PCI-6034E for measurement. After DAQ gets data, I send them to another computer through serial port (com1). I write a Virtual C++ program, which calls NI-DAQ library functions to implement DAQ data sampling (multiple channel scan) and sends measurement data to another computer through serial port under request. DAQ data sampling and serial communication are implemented in two threads. They are running concurrently. They share a global memory for measurement data. The serial communication thread will do infinite wait and send data only when another computer sends a request through serial port.

I met two problems. First, when I reduce the size of DAQ measurement buffers (piBuffer and halfpiBuffer, I us
edouble buffer model), DAQ measurement is often interrupted by the message "[DAQ_DB_HalfReady] returned NI-DAQ warning 10846. Your application was unable to retrive data from the background acquisition buffer fast enough so the unretrieved data was overwritten with new data. ...". I want to get run time data so I need to reduce the buffers as small as possible. How can I solve it ? The second problem is that the serial port gets error data (nothing) from measurement computer sometimes, especially when DAQ initializes itself and finishes work. It looks like that there is a conflict between DAQ and serial port. Does anyone have similar experience about this? Any suggestion?

Thank you in advance.

Le Cai

[JustinBritten]

Le Cai,

If you acquire more data than will fit in your buffer, then the buffer acts as a circular buffer, and is filled more than once. You will get an overwrite error (-10846) if you do not read data out of the buffer before it is overwritten with new data.

There are several factors that affect your ability to keep up with the acquisition: the scan rate, the size of the data buffer, and the number of scans to read at a time. If your buffer is too small, or you are not reading data out of it fast enough, then you will get the overwrite error. If your buffer is too big, you may get an out of memory error.

Experiment with different values for scan rate, buffer size and number of scans to read at a time. The best combination will result in lit
tle or no scan backlog. A good rule of thumb to start with is: make your buffer size 2 - 4 times as large as the number of scans to read.

Additionally, performing less processing in the read loop can help avoid the -10846 error. Lots of run-time processing in your read loop will slow the acqusiition down and lead to a buffer overflow. To solve this you can either write your data to a file and perform post-analysis or you can create another thread and hand off the current buffer to analyze to the second thread. Therefore, your acquisition thread can continue to run without being slowed down by the processing you are performing.

Regards,
Justin Britten

[le]

Thank you for your answer. It really helps me.

I have two more questions. One is about the buffer size.
In your answer, you suggested me to use a buffer whose size is 2-4 times as large as the number of scans to read. What's the meaning of the number of scans to read? In my understanding, the number of scans to read is equal to the half size of buffer in double buffer mode. If it isn't true, plz correct me. For example, I set the scan freqency as 100HZ for each channel and three channels are scaned each time. I want to get measurement data per 0.1 second. So I use a buffer size of 100*3*0.1*2=60. Can I increase this size without increasing my period to get data?

The second question is about creating another thread to handle data. Actually what I did is li
ke this. I create another thread to read the data stored by DAQ measurement thread. DAQ measurement thread periodically stores data to a global memory (not any buffer used by DAQ). The second thread will read these data. Both threads access this global memory through mutual exclusion. Only one can get in and write or read data. For DAQ measurement thread, this operation is in the middle between two continuous half buffer readings. My observation is that if I run this second thread, DAQ will suffer error 10846. Any suggestion about this situation? Thank you so much for the help.

Best regards,
Le Cai

[JustinBritten]

Le Cai,

You are correct that the number of scans to read is equal to half of the buffer in double buffer mode. I was mistaken and referring to a standard (non double buffered) operation. However, you can increase the size of your buffer without affecting the period of your acquisition. A buffer of 60 is quite small and, as such, will be more prone to overflow errors. The rate is actually set through the DAQ_Rate() and DAQ_Start() functions. For more information on these functions and how to configure the scan rate, please see the NI-DAQ Function Reference Manual.

NI-DAQ Function Reference Manual for PC Compatibles
http://digital.ni.com/manuals.nsf/websearch/1630A0B68738B269862567C1007A2912?OpenDocument&node=132100_US

A good place to start would be the example titled, "DAQdoubleBuf.c" which ships with the NI-DAQ driver. If you installed the examples for Visual C++ when you installed the NI-DAQ driver you should be able to find this example in the \Program Files\National Instruments\NI-DAQ\Examples\VisualC\AI folder on your computer. This example would be a good template as it is very close to what you are trying to do.

If you observe that you only receive the overflow error when you are operating the two threads, thus ruling out the buffer size as being a potential problem, you may want to examine whether or not your second thread is placing a lengthy exclusion on your data buffer during the period when your first thread is trying to move the data. If your first thread has to wait during the half-buffer transfer this could easily cause the overflow, as the acquisition would be running but the transfer would be paused. Instead of placing a mutual exclusion around one piece of global memory you could try using a queue instead. A queue approach will allow you to pass the data from the first thread into a queue to be read, when convenient, by the second thread. In this method the first thread would never have to wait as the transfer would just be a handoff.

Regards,
Justin Britten

Applications Engineer
National Instruments