- From: <brad.keryan_at_ni.com>
- Date: Tue, 5 Nov 2002 14:58:54 -0600
Sorry, I haven't been following the Comedi list very closely in quite a
while, hence the late reply. And please excuse Notes's lame reply quoting.
Anyway, all SCXI analog input modules (not just the "higher dollar" ones)
support doing a hardware controlled scan, where the multiplexer on the SCXI
module is controlled by the SCANCLK pin on an E-series DAQ board (which can
be routed to other modules in the same SCXI chassis). On most of the older
modules you can only scan channels sequentially (you program a start
channel, so you can scan that start channel and any number of channels
after it), but some of the newer modules have a channel FIFO so that they
can scan channels in any order. This scanning mode of operation doesn't
require using a GPCT. Rather, it uses the same timing circuitry that is
used to control a hardware timed acquisition.
As for settling times, they vary widely depending on which modules you have
and what gain/filter settings you are using. The specifications pages in
the SCXI module user manuals list the recommended settling time between
channels (eg. if you are programming a scanlist and having the DAQ board
clock the SCXI multiplexer, this is how slow your clock must be to get 12
bits of accuracy, and that is how slow it must be for 16 bits, etc.). Also,
on some modules, a delay is necessary after writing to certain registers
(such as the gain register on the SCXI-1102); this delay can be as long as
3 seconds, on modules with a 2Hz filter.
All of this used to be fully explained in the user manuals for the older
modules (such as the SCXI-1100, SCXI-1120, SCXI-1140, and such) which had
complete register-level programming instructions with examples. Some other
modules have separate register-level programming manuals, and some others
have only our internal documentation (some of which I have provided to
Caleb Tennis in the past). You can still find the older manuals on our
website (http://www.ni.com/manuals ; click on "all manual revisions").
The analog input module and digital I/O modules don't support scanning, so
they work as described previously: you write to the registers on the
modules to directly control DACs and I/O pins.
I haven't really worked with Comedi in well over a year, so Caleb Tennis
probably has the most complete SCXI codebase for Comedi. From how it
sounds, it would make a very good starting point for someone who wanted to
implement SCXI scanning, and it's already usable for single-channel
acquisitions.
Brad
"Caleb Tennis"
<caleb_at_aei-tech.c To: "Calin A. Culianu" <calin_at_ajvar.org>
om> cc: comedi_at_comedi.org, dchristi_at_med.cornell.edu
Sent by: Subject: RE: Fwd: Re: NI SCXI and E series boards
comedi-admin_at_come
di.org
10/14/2002 01:51
PM
> -----Original Message-----
> From: comedi-admin_at_comedi.org [mailto:comedi-admin_at_comedi.org]On Behalf
> Of Calin A. Culianu
> Sent: Monday, October 14, 2002 12:43 PM
> To: Caleb Tennis
> Well, to my own discredit I have never used Labview. We were never big
> Windows people here and after discovering Comedi I decided to stick to
> C in (realtime) linux kernel modules with comedi. :/
Maybe so and maybe not. After migrating to Linux, I can do anything with
comedi and Qt/KDE that I could do with Labview.
> I would be _extremely_ grateful for that. It isn't useful yet, but if
> you send it now, at least I can take a look at the code and see how one
> goes about talking to these modules. It would be great actually! :)
You may want to preliminarily take a look at patch-scxi in the
comedi/patches directory. It basically adds a subdevice called SERIAL
which
takes over the DIO lines. The timings and etc. are all in there.
> We haven't yet gone out and bought an SCXI system, we are still doing a
> feasibility study of sorts to figure out what would work well for us. We
> plan on doing mapping of cardiac tissue (a two dimentional 8x8 grid at
> first) with a sampling rate sof 1kHz per node on the grid (for a total of
> 64kS/s). We figured we could probably get 1 E-series NI board and two of
> those SCXI-1100 32-channel modules for signal conditioning. We also
would
> need to do control on a per-sample basis.. meaning we need to be able to
> react to data in hard realtime and issue 1 or 2 AO signals out again, to
> stimulate the tissue. Is this feasible, in your opinion?
That may be pushing it, though maybe not. The newer SCXI devices have a
maximum clock cycle time of 600 nanoseconds - if we assume that it takes 32
bits, we're looking at ~20 microsecs to issue a channel setup command.
Currently, the driver uses the kernel functions and isn't able to do
anything fancier than a usleep, so we're actually at 32 microsecs or so to
issue a command. I go with the assumption that by the time I can issue the
comedi_data_read, the mux signal has settled, and that logic works for our
aquisition.
I don't see any reason why you couldn't use a GPCT for the timing, but it
is
physically cabled to a DIO pin, so you would have to configure that pin as
an input. It may be possible to make the connection internally through
commands to the SCXI-1100 as well.
The higher dollar modules do allow you to set up multiple channels in a
scan. IE, you can put 32 channels into your scan loop so that each time
you
acquire one, it zooms to the next without having to issue a new command.
I'm not familiar with that function, but I know it's doable, and would save
time on switching.
Would you need to evenly space out your 1000 Hz aquisition amongst all 64
channels, (e.g. sample channel 0, sample channel 1, sample channel 2....
sample channel 31), or can you do 1000 acquisitions of one channel before
moving on to the next?
I'm not sure the sensor type you will be using, but as an alternative you
might be able to use one of NI's 64 channel analog in E series boards (the
number escapes me at the moment), and create your own signal conditioning.
A good differential amplifier circuit, or a Mighty Module, or something
else
might just give you what you need.
Brad Keryan (brad.keryan_at_ni.com) has been my link to NI support for the
SCXI
modules for linux, and he has done an excellent job at supporting us. He
wrote the comedi extensions and would definitely be knowledgeable about
what's feasible with SCXI.
> Wow. Well that would be cool, although our signal conditioning on AO
need
> not be so nice. I think for AO, since there are such few signals for
> stimulation (probably 1 or 2, 6 at most), we could just use another
device
> external to the system -- one triggered by either DIO lines or AO lines
> on the DAQ board.
You could also use the AO on the board. We buy the cheap boards (PCI-6023,
$395) that don't have AO so it was an option we explored at one time.
> So you have to control the synchronization yourself in software? Hmm.
> What's this I read in the NI catalog about using the DAQ board's internal
> timer. Is that doable too?
Probably, but don't hold me to that.
> Right -- each module has its own spec with respect to how fast it can
> sample. Hmm.. so what you are telling me is that this is heavily
> driver-driven acquisition. It kind of makes things messy for us, in that
> we have to constantly be talking to serial lines to tell the multiplexer
> what to do, then quickly grab a sample off the board, then repeat for the
> next channel. Does this involve a lot of comedi_data_read() calls, or
> would the asynchronous interface in comedi actually work?
Yes, very heavy driver aquisition. Currently it's all asynchronous, but it
could be changed. If you wanted to pick it apart I'm sure you can make it
much better. I know I'd appreciate it! :)
Caleb
_______________________________________________
comedi mailing list
comedi_at_comedi.org
https://cvs.comedi.org/cgi-bin/mailman/listinfo/comedi
Received on 2002-11-05Z20:58:54