continuous analog acquisition with DAQmxBaseReadAnalogF64

[elisabeth]

John,

i do not want to bother you with my problem, but retreiving 100 samples at a frequency of 250 hz with a timeout of 1s is NOT what I want to do ( this was just to give an exemple, to show that there is no problem running my code when the timeout is correct). If I put a shorter timeout as you suggest, no value is returned by the function, so I cannot retreive the values in the buffer.

The problem is that, even if I know the frequency of my input signal, I do not know how long the code takes to execute ... and it takes time :

If I read samples 5 by 5 at a frequency of 250HZ running my program during 10 seconds, i retreive only around 1160 samples ( the value is different each time I run it, and it also varies a lot depending on hte computer I am using).

So it means that after 1 hour, I will be processing samples that have been acquired a long time ago ... while I want to be as real time as possible.

So my problem is : how do I ensure I read up to the last acquired samples, without knowing how many samples I have in my buffer ?

Thanks ,

Elisabeth

[WM_John_Weeks]

The only option I see is to use the technique I suggested originally, but make sure you check for the correct error message. That is, follow my advice but not all of it 🙂

In this very old thread I was dealing with similiar issues:

http://forums.ni.com/ni/board/message?board.id=250&message.id=11016&view=by_threading&page=1

Reviewing this, I see that zero timeout doesn't work. Note also in this thread that the NI engineer Malcolm says that it wasn't originally intended that reading continue after a timeout, but that he had resolved the issue in a newer build. At the time I was using DAQmx Base 1.4.0f2. I think I abandoned DAQmx Base before 1.5.0 came out so I never went back to test the fix.

The thread does imply that you should be able to use a small but non-zero timeout, and use the returned number of samples read. I think that would be the easiest way to read indeterminate subsets of the data.

If it doesn't work, then I don't think you have an alternative but to read small chunks of samples that are short enough that you never time out. It would have to look something like this (clearly not real code):

double data[1000]; // whatever size is needed
int32 i = 0;
int32 delta = 5; // set to the small number of samples to read each time
do
DAQmxBaseReadAnalogf64(short timeout, &(data[i]), ...)
i += delta;
while(some condition)

This would be probably be embedded in something else, and there would be more code inside this loop...


It was issues like this that led me to abandon DAQmx Base. I know that's not an option for you. I feel your pain 🙂

[elisabeth]

John,

Thanks for letting me know of the previous thread on this subject. Unfortunately, the behavior on my linux PC really seems to be different from yours: it is not that I am loosing

a few data : I cannot retrieve any of it unless the buffer can be fully filled up by the acquired samples 

When I try in "continuous mode" instead of "sample mode" I get the general bug that Tom describes : only 2 values are read.

If I read data small chuck by small chuck as you suggest, I will be very late as compared to the current values I am acquiring, so I will not have a real time behaviour...

It just seems to be impossible to retreive data real time when you have continuous data coming in with the DAQmxBase driver

Too bad as I bought my USB -6008 especially for that purpose...

Thanks for your help John,

Elisabeth

[cesarabravop]

Hi There

It we seems to me that DAQmxBase user have a lot of problems relates to timeout.

In the following I will summarize my personal experience with several issues related

to timeout problems. Perhaps this report can be use useful to the community and, also,

I would like to hear some workaround to my particular problems.

First thing first: Environment:

Develop platform:

PC running OpenSuSE 10.3,

RAM

HD 80G

USB 1.0 physical port

Production platform

Industrial PC VIA, with CELERON processor 700Mhz

USB 2.0 physical port connecting through PCI bus

DAQ device: NI USB6210

Driver installed  (the same in both platforms) : nidaqmxbase-3.2.0

Our application must be aware of some waveform corresponding to fast oscilography events

and also, calculate RMS values for some analogical inputs (this can be done at low sample rate).

I think that the model to achieve these task is in the following example installed with the Windows version

of the driver:

"C:\Documents and Settings\All Users\Documentos\National Instruments\NI-DAQ\Examples\DAQmx ANSI C\Synchronization\Multi-Function\ContAI-Read Dig Chan"

Of course the example above WILL NOT WORK on Linux because it is targeted to NIDAQmx which is no totally equivalent to the NIDAQmxBase available on Linux. 

This kind of synchronization example is lacking in the set of examples available on Linux at:

/usr/local/natinst/nidaqmxbase/examples 

So, my first two questions for the NI support team around is:

Can you provide me with AN EQUIVALENT piece of code FOR NIDAQmxBase so that I can simply compile it and try to adjust to my application?

Or maybe (God forbid!) the particular hardware 6210 is not able to do this kind of synchronization?

Of course we are done already some -intensive- testing with the 6210, but always we got problems with timeout.

So, we test for timeouts VALID values and discover that timeout greater than 30 seconds simply freeze the application.

Well, I suppose is the driver who freeze, but to the final user (me for a while) it looks like the program "is not responding".

Attention: the host operational system works fine thanks, while this problem happens. You can check this problem, with

the example:

/usr/local/natinst/nidaqmxbase/examples/ai/contAcquireNChan.c

changing the 10 seconds while for an infinity one. 

So the question now is: Is this a "feature" ? Or there is a way to set a timeout greater than 30 seconds?

The question and the quest for a greater timeout rises because, when a timeout occurs, the message

is something like

"DAQmxBase Error: <err>Some or all of the samples requested have not yet been acquired.

To wait for the samples to become available use a longer read timeout or read later in your program. To make the samples available sooner, increase the sample rate."

But: How can you set a longer timeout if the max working value is 30 seconds?

Of course a 30 seconds timeout seems to be too much for applications that must acquire data

which is volatile in terms of miliseconds. So perhaps (this is a brighter idea from the IT personal)

the  right thing to do is to "increase the sample rate". So let´s take a look to the sample rate configuration.

The maximum sample rate of the USB6210 is 250kS/second for a single channel. Correct me if I am wrong

but this mean that the maximal sample rate for "NumberOfChannels" channels to acquire is a function of the

quantity of channels to be acquired, something like:

maximalSampleRate(NumberOfChannels) <=  250kS/NumberOfChannels

So. for example, (I had not made mistakes), the if we need to acquire 10 channels this amounts to

maximalSampleRate(10) <=  25kS/second

And this way, there is a well defined upper limit to the sample rate which can be defined for a specific tasks.

Or maybe I am wrong and there is a way to work around any timeout problem by defining an

"adequate" (whatever it means) sample rate?

Considering the sample rate upper limit explained above, we try to find the best parameters

to acquire 10 channels at the maximum possible sample rate so that we can save files with

ten cycles of waveform which will be processed for other modules apart from the data-aquiring module.

This imply a choose of the buffersize (number of samples per channel) and the size of the DMA buffer.

We try out with several values (small values with respect to 4k bytes hardware buffer; also we try out

values greater than 4k bytes) but up to now, any combination of "number of samples per channel buffersize"

and DMA buffer size ends in a timeout condition. In particular the values in the example 

/usr/local/natinst/nidaqmxbase/examples/ai/contAcquireNChan.c

set "number of samples per channel buffersize" and DMA buffersize to the same value, but this combination

in fact works only for some minutes (depending of the USB channel velocity and microprocessor clock) until reach

a timeout condition.

Of course we try to catch the timeout condition and recover. Since we regret to lost data, we

simply execute an "DAQmxBaseStartTask(taskHandle)" instruction and, with this strategy,

we in fact, can read some more times... Only to reach -some minutes later- a timeout condition

which can be no treat this way.

What seems to lack is an optimal(?) relation to setup the variables

- Number of channels to acquire

- Sample rate

- buffersize (samples per channel to acquire)

- size of DMA buffer

which allow to do continue data acquisition WITHOUT TIMEOUT (of perhaps with minimum timeout per day: one or two being acceptable).

After theses comments my question for the NI support is:

There exists any kind of "golden rule" relation for these variables?

Perhaps a recipe "ready to cook" that you can provide us to complete our application?

Thanks in advance

César

cesarabravop@hotmail.com