RE: Fwd: Re: NI SCXI and E series boards

> -----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

Received on 2002-10-14Z17:51:05