Hi There
It we seems to me that DAQmxBase users 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, Linux 2.6.22.5-31-default i686
Processor (CPU): AMD Athlon(TM) XP 2000+ Speed: 1.261,31 MHz
RAM: 504,1 MB
HD 80G
USB 1.0 physical port
Production platform
Industrial PC VIA, running OpenSuSE, Linux 2.6.22.5-31-default i686
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
