| Re: IDL verses other interpertative languages (tcl/tk, khouros, pv_wave, etc). [message #10549] |
Wed, 17 December 1997 00:00  |
rivers
Messages: 228
Registered: March 1991
|
Senior Member |
|
|
In article <3496CA0E.DD25021F@sandia.gov>, "Stuart E. Murray"
<semurra@sandia.gov> writes:
> I am working on a Satellite Sensor Simulator and will require that I
> display several windows of data. I am trying to sort out what display
> package might be the best bet. My group currently uses IDL and tcl/tk
> and I have been asked to considered them since they are in house. I have
> talked with these folks about both languages and both have strong view
> points. It is obvious to me that this discussion group will also. But,
> for the sake of argument. I will pose this question on the tcl
> discussion group as well.
> 1. I will have a real-time connection to another embedded machine.
> 2. There will be one data spigot (be it parallel port, USB, serial port,
> or network) to the other embedded machine. Does IDL support interfaces
> such as those or do I have to write my own drivers?
> 3. Has anyone used IDL in a real-time environment successfully (or
> unsuccessfully)?
We are doing exactly those types of applications at a number of synchrotron
radiation beamlines at Argonne and Brookhaven National Labs. IDL is
successfully (and easily) controlling and displaying data from many real-time
experiments. IDL can call C code directly, and it is really very easy (the
hardest part is usually learning how to create shareable libraries under your
operating system).
The types of "data spigots" we are using include
- VME crates running vxWorks and communicating on the network via TCP/IP
- CAMAC crates with direct computer bus interfaces
- Multichannel analysers with network interfaces
- Frame grabbers with computer bus interfaces
You get the picture - if you can talk to the device from C you can talk to it
from IDL. For the kinds of experiments we do, which are frequently
reconfigured IDL is really nice, since it is a nice scripting language.
The recent addition of object oriented techniques makes it even more powerful.
Here is an example: the IDL class 'EPICS_MOTOR' talks to stepping motors which
are controlled in a VME crate running vxWorks and the EPICS control system.
Here is all that a user has to program to move a motor and wait for it to get
to its destination:
motor = obj_new('EPICS_MOTOR')
motor->move, 10.
motor->wait
> 3.1 The display of data in real-time may not be a strong issue if you
> can throw a lot of horsepower at the problem. However, since IDL is an
> interpertative language, you have to wonder about the impact of
> performance over straight compiled code? Is this a problem? Is Windows a
> problem?
IDL graphics are very fast, as fast as most compiled packages, because typically
just a few interpreted statements are required to produce a complete graphics
display. The real work is done by IDL internal routines, which are compiled C
code.
We use IDL for >10 Hz display of spectral (1-D data) and for real-time
microscopy (imaging).
> 4. How hard is it to incorporate C/C++ code into IDL? Literature
> suggests a thorough knowledge of IDL before attemping this and I don't
> have that yet.
See above. It is NOT difficult. Basically this line is what you need:
result = call_external('MY_LIBRARY', 'MY_ENTRY_POINT', param1, param2, ...)
You just need to create MY_LIBRARY as a shareable library with your C compiler
with MY_ENTRY_POINT globally visible.
> 5. IDL will probably be executed on a Laptop (166 MHz or better) under
> Win95 or NT (the OS may have a Real-Time exec handler, although there
> are people that would question a Real-Time exec handler can be done
> correctly). Other real time OSs might be considered like VxWorks, QNX,
> etc.
I am not sure I indestand you here - IDL cannot run under vxWorks or other
real-time OS. I use it under Windows NT, VAX/VMS, AXP/VMS, and many Unix
flavors (sun4, Solaris, Digital Unix, IRIX, HPUX) and am doing real-time data
collection and control on all of these platforms.
6. IDL learning curve steep?
It is different, but IMHO a lot more familiar to most programmers than tcl.
> 7. What is the downside of IDL? (bloat code, etc).
> 8. IDL cost (both for the software & maintenance of code)? How easy is
> it for someone to come in and pick up where you have left off?
Maintenance is not a big issue. IDL is expensive, but people are much more so.
I have no trouble justifying IDL cost in terms of save man-hours compared to
third generation languages. It really shines when you want to try things
quickly.
____________________________________________________________
Mark Rivers (773) 702-2279 (office)
CARS (773) 702-9951 (secretary)
Univ. of Chicago (773) 702-5454 (FAX)
5640 S. Ellis Ave. (708) 922-0499 (home)
Chicago, IL 60637 rivers@cars.uchicago.edu (e-mail)
or:
Argonne National Laboratory (630) 252-0422 (office)
Building 434A (630) 252-0405 (lab)
9700 South Cass Avenue (630) 252-1713 (beamline)
Argonne, IL 60439 (630) 252-0443 (FAX)
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
