Driver Development Kit (DDK)

cancel
Showing results for 
Search instead for 
Did you mean: 

Accessing samples from a CIN that calls COMEDI driver

I am wondering about access to samples/measurements using a CIN that uses a comedi driver while the CIN is still running.
Ideally, I'd like to display data continuously, as it is read in with the acquistion card (NI-6071E).

The current state of affairs is that my data acquisition successfully terminates after some finite number of samples are collected, and then data is displayed in labview v6.1. That is, only after all samples are taken is the data ever displayed in labview graphics.
I don't know if it's possible to display graphics "real-time" in this way--I suspect not.To the best of my knowledge, labview requires that a
CINterminate execution before moving on to the next step, eg displaying graphics
.
Is it possible to have access to the samples being read by the CIN while the CIN is still running? If so, how?
(I use comedi drivers, redhat8.0, and a modified VI to control a CIN, originally downloaded from the NI website.)thanks.
0 Kudos
Message 1 of 4
(7,396 Views)
jonny e wrote:

> I am wondering about access to samples/measurements using a CIN that
> uses a comedi driver while the CIN is still running.
> Ideally, I'd like to display data continuously, as it is read in with
> the acquistion card (NI-6071E).
>
> The current state of affairs is that my data acquisition successfully
> terminates after some finite number of samples are collected, and then
> data is displayed in labview v6.1. That is, only after all samples
> are taken is the data ever displayed in labview graphics.
> I don't know if it's possible to display graphics "real-time" in this
> way--I suspect not.To the best of my knowledge, labview requires that
> a
> CINterminate execution before moving on to the next step, eg
> displaying graphics.
> Is it po
ssible to have access to the samples being read by the CIN
> while the CIN is still running? If so, how?
> (I use comedi drivers, redhat8.0, and a modified VI to control a CIN,
> originally downloaded from the NI website.)thanks.

The way to do this is to not let the CIN run until all the data has been
aquired but instead return prematurely with only the part of the data
which has arrived in the intermediate buffer up to that point. Then
after the data has been plotted, saved, or done whatever you want, call
the function again to receive the next block of data. This has been the
way to do this since LabVIEW 2.x and still is the most simple and most
compatible approach.
Anything else requires some special communication channels which are not
available in most LabVIEW versions, definitely not documented yet and as
such most likely going to change in the future eventually.

Rolf Kalbermatter
Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 4
(7,396 Views)
Thanks very much for the response.
Do you know how repeated executions of the CIN and plotting data will effect max sampling rate? Obviously, it will decrease it, but do you have an intuition or experience by how much it will decrease?
I'm not sure I can use the method you described above with sampling rates that are "high." Seems that if I'm busy saving/plotting data and repeatedly calling the CIN there would be samples I miss above a certain desired sampling rate. I'm sampling 16 channels at 25kHz, which is about 1/2 the max sampling rate possible using DMA.
At any rate, I'll give it a shot and see what happens.
cheers.
0 Kudos
Message 3 of 4
(7,396 Views)
jonny e wrote:
> Thanks very much for the response.
> Do you know how repeated executions of the CIN and plotting data will
> effect max sampling rate? Obviously, it will decrease it, but do you
> have an intuition or experience by how much it will decrease?

It all depends on what you do with the returned data. Obviously if you
would display it in a chart, make some very involved data analysis,
write the data plus analysis results to disk and do 200 other things
every time you return from the CIN with yet another tiny bit of data you
will eventually slow down the system to the point that the intermediate
buffer has filled up before you return to get the next chuck of data
from the CIN.

> I'm not sure I can use the method you described above with sampling
> rates that are "high." Seems that if I'm busy saving/plotting data
> and repeatedly calling the CIN there would be samples I miss above a
> certain desired sampling rate. I'm sampling 16 channels at 25kHz,
> which is about 1/2 the max sampling rate possible using DMA.
> At any rate, I'll give it a shot and see what happens.
> cheers.

It depends on how the CIN and the underlying device driver are written.
If the CIN directly gets the data from the DAQ card the only buffer you
have is the FIFO. So in that case you might very soon have a problem. If
the CIN relies on a real device driver to transfer the data through DMA
or interrupt into an intermediate circular buffer this operation has
typically a much higher priority than your application level which is
displaying, calculating and whatever it does. The only problem then will
be if the intermediate circular buffer fills up before your application
gets around to get the next block of data. This is the mode NI-DAQ
typically uses and the maximum data acquisition rate is of course
dependant on the CPU speed and additional tasks you want to do but
typically is higher than if you would not use such an intermediate
circular buffer.

I have no idea how the Comedi CINs work in detail and if they do use
intermediate circular buffers on device driver level, often also refered
to as double buffered acquisition. If they do, it should be simple to
adapt the CIN to work as I have pointed out. Otherwise you won't be able
to do this very well without redesiging that part of Comedi.

Rolf Kalbermatter
Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 4
(7,396 Views)