emulation of DAQ card -- am I reinventing a wheel that is made already?

[jim_monte]

Hi All,

I am writing a general-purpose data acquisition program in C and am wondering if I can take advantage of existing code somewhere to help with its testing. It takes command line arguments describing the device, channel parameters, and some tuning parameters, and it logs analog data to a CSV file. My first cut worked OK, but it is limited to about 400 kSamples/sec before it starts having buffer overruns. I found that the conversion from binary form to the text of the CSV file is the bottleneck limiting its speed. So I am writing a multithreaded version that offloads the conversion work while doing the reads from the NI buffer. The multithreaded version is more complex, and I need a way to test it for correct operation -- logging text strings in the right order and only after they are valid. I have created a primitive emulator of an NI card that processes the DAQmx* functions that I am using. It is basically two threads, one simulating data acquisition and invoking user callbacks and the other doing work related to these. Two differences from a real card are that it outputs a deterministic sequence of values so I can check for correct logging order, and the other is that it stops at full-buffer condition to allow for stopping the program while debugging without getting buffer overruns. As I kept adding code to make the emulator work, I started to think that this is must be a fairly common requirement and wondered if there is one already available in source code form. Does anyone know of such code? I know that simulated devices can be created, but I do not think that would address deterministic data or preventing buffer overruns. Or am I missing something? Thanks for any information.

Jim

[nyc_(is_out_of_here)]

http://www.ni.com/tutorial/3698/en/

[jim_monte]

The noisy sine waves of the simulated device are OK for validating correctness. They are not the best because the correct values are only approximately known, but they are usable. But I did not see any way to make the simulated devices avoid buffer overruns during debugging, and without that feature they are not very useful when stepping through code. My output with a simulated device while debugging looks much like that for a real one:

Press Enter to stop...
Sampling continuously.
Unable to read data.
NI returned -200279: The application is not able to keep up with the hardware ac
quisition.

Increasing the buffer size, reading the data more frequently, or specifying a fi
xed number of samples to read instead of reading all available samples might cor
rect the problem.
Property: DAQmx_Read_RelativeTo
Corresponding Value: DAQmx_Val_CurrReadPos
Property: DAQmx_Read_Offset
Corresponding Value: 0

Task Name: _unnamedTask<0>

Status Code: -200279.

[Cooking_Up_Code]

When you simulate the device, try using test panels in NI MAX to verify that the sampling rate and samples to read you are configuring won't throw a buffer error. The error you are recieving has to do with not having enough samples to read for your Rate. The sampling rate sets the hardware's rate of acquisition, but the samples to read refers to the amount of samples your computer takes from the onboard FIFO to the PC buffer. If  your samples to read is too low, then the FIFO can overflow.

[jim_monte]

Thanks for the reply, but the issue is not the selected sampling rate or buffer size per se. An extremely slow rate that would be appropriate for avoiding buffer overruns when the program is stopped to review variable values could be orders of magnitude too slow during other times when the values are not being inspected as closely during the same execution of the program. A sufficiently large buffer to store samples while the application is stopped may not be possible and may hide some errors even if it were. The appropriate thing to do when the application is stopped to review its internal state is to stop the data acquisition as well.

Jim