NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/sci/compaid/150

Text File | 1992-07-27 | 6.7 KB | 138 lines

Newsgroups: sci.comp-aided
Path: sparky!uunet!mcsun!news.funet.fi!ousrvr.oulu.fi!phoenix.oulu.fi!eha
From: [e-mail] (Esa Haapaniemi)
Subject: LabWiev & equivalents
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: University of Oulu, Finland
X-Newsreader: Tin 1.1 PL4
Date: Tue, 28 Jul 92 09:42:47 GMT
Lines: 126

As I read from some previous post about things that is needeed in laboratory
I'd like to give a small ad. Please forgive me, if this is not allowed
here (I've been here only about a week).
This conversation is taken in [e-mail].

From: [e-mail] (Pete Goodeve)
Subject: Re: What does the Amiga lack?
Date: 26 Jul 1992 09:29:56 GMT
Organization: University of California, Berkeley


|> LabView is pretty cool (and its also available for MS-DOS).  We don't use it
|> here, but I read about quite some time ago in an article on graphical
|> programming (either BYTE or Dr. Dobbs, I don't recall which).  This system
|> provides software versions of gauges, buttons, graphs, etc. that you normally
|> find around a lab, and ways to hook them together into a data aquisition
|> system.  It's pretty specialized, but I imagine it would be fun to hack in.
|> It's in some ways the same idea as AmigaVision, but oriented toward lab work
|> rather than presentation authoring.  The idea is that anyone can assemble
|> such an application, and rather quickly -- you don't need a programmer
>
> I work in a brain electrophysiology lab and we use Labview II extensively
> for signal processing. Labview comes with an extensive library of signal
> processing "VIs" (the Labview metaphor is the Virtual Instrument or "VI").
> So, to build a VI in Labview, you take the built in functions, which are
> represented by icons with input and output nodes, assemble them into modular
> sub-VIs, with their own input and output nodes, and wire them together. The
> data then flows along the wires to the various sub-VIs, getting processed
> along the way. Just about anything that you can code up in C, you can code
> up in Labview. It isn't always easier or more efficient but it can be done.
> It is coding for electrical engineers.
>
> [.....]
>
> It is the existance of applications like Labview that has me doing my real
> work on Macs instead of my Amiga.


[Well, OK -- I have mentioned it once before in this group, but this gives
me a good excuse to do so again... (:-))]

There *is* now a programming environment akin to LabView on the Amiga!
We believe that it's -- at least potentially -- considerably superior
to programs that run on other platforms, like LabView, because it takes
full advantage of multitasking in ways that would be hard on a Mac or PC.

I say "potentially", because for one thing the system is fairly new,
and it will take time to develop a wide range of modules; the current
set are designed to process acoustic waveforms (and are being used in
a research lab), but it should be possible to extend them to almost
any form of data.  More serious is another `lack' on the Amiga, not
of software but *hardware*.  There are very few cards that can connect
the machine to an experimental environment.  The existing installation
either works through a custom interface (with driver modules written
by the researcher) or from previously recorded data.

For example, the only Analog-to-Digital card I know for the Amiga is by
ACDA, and I am not impressed.  Would you believe -- on a multitasking
machine -- that it doesn't provide for interrupts?!  Doesn't have any DMA
either of course.  Not too bad I suppose if you're doing single 25 microsec
conversions every millisecond or slower, but you're kind of stuck if you
want to chain a lot of conversions at top speed, or -- in the other
direction -- if you want to use the on-board timers to keep a slow tick
rate for the conversions.

ASDG's GPIB (IEEE 488) interface, on the other hand, looks pretty nice.
Problem is, you probably have to write a control module for each instrument
you connect this way, because they all have their own command protocol.
(Not usually that big a job, but it does mean you can't plug and play...)

                               ---

So, what *is* this program, then?  We call it "The Web", as a reasonably
descriptive title.  It actually is more a suite of programs that cooperate
closely with each other, rather than the single monolithic monster you are
liable to find on other machines.  Overall control is through a "Diagram
Window" where the acquisition and analysis configuration is constructed
from the desired elements.  You simply place these in the window with the
mouse and connect them together as you wish.

Each distinct *type* of element is provided by a separate program, so there
is no problem adding new types.  Each of these `Module' programs manages
all of its instances in the configuration, handling things like pop-up
parameter panels; it also naturally provides all the data algorithms
relevant to that type of element.  It does *not*, however, normally run
these algorithms itself: each linear `path' of connected elements is
represented by a single process, from which the algorithms are invoked
directly.  This way we have the absolute minimum of task switching, so
things are *fast*.

An important component of the system too is Dave Navas' `SHADOW' library,
which provides object oriented `communal services' and resource management
for the modules.  For example a single `Master' module manages all the
gadgets that an element might need in its parameter panel.  Writing your
own custom module is mostly just a matter of slotting your own data functions
into a standard framework, and specifying the gadgets you want in a sort
of `tag list' format (similar in concept to but more extensive than the
2.0 tag list scheme).

You might want to think about other things this could be applied to.
The structure of the data -- and it *is* structured and self-identifying,
not just a stream of values -- passed around the system could be arranged
in almost any way you desire.  You could pass bitmaps -- anim frames for
instance -- through a series of filters before displaying them.  You could
do MIDI very nicely, but maybe there's enough competition in that area
already.  And yes, you can split and merge data streams, or have elements
that take data from more than one input channel or generate more than one
output.  Very flexible.

                                        -- Pete --


============================================================================
The above statements and opinions are those of the author, who is not
speaking for the University of California in any way.
============================================================================

End of included article.

Any comments ?

Esa Haapaniemi
University of Oulu
Department of Chemistry
Finland