Following up on Don's Lab View note:
The main PC Lab View limitation is the Windows operating system
which disables the interrupts for various time intervals. It can do
"real time" data collection by using timers and FIFO stores on the
ADC board so that the CPU isn't involved in real time transfers. The
CPU must unload the FIFO before an overflow occurs but that isn't
real time.
The Automation Lab at the Swiss Technical University at Lausanne
(EPFL), Switzerland have been using Lab View for real time input &
output (they do control of an inverted pendulum, helicopters etc.)
on Power Macs which have a clean interrupt structure (unlike
Windows).
The Power PCs are expensive to buy, hence my use of PCs, and my move
to RTLinux. Now if someone could just port over those "visual basic"
type tools to X-Windows....
> On Thu, 19 Nov 1998, Basham, Richard R wrote:
>
> > In case some of you do not know anything about LabView, it is a graphical
> > language. It allows the "programmer" to attach icons, that define
> > functions, together to create a program. I am a tried and true C programmer
> > myself and believe that it is a better language. However, LabView has one
> > standout quality. It has the ability to let the "programmer" build nice
> > looking graphical user interfaces. It is a fast easy way of producing data
> > displays with graphs, thermometers, gauges, buttons, etc. What I have found
> > is that for my applications, 1 ms periods and better, it does not perform
> > well by itself. However, combined with RT-Linux I think it can be a very
> > useful tool. I do not have it myself. I plan on purchasing it soon. If
> > there are others out there who have been using it or are planning on using
> > it, I would like to here your reviews.
>
> LabVIEW is a good hook for some beginners that need to get something done
> quickly; it is, in a sense, the "Visual Basic" of data acquistion and
> instrument control. I would say its performance is poor and unsuitable for
> real-time tasks requiring sub-Hz periods (this has a lot to do with the
> fact that I have run it on Windows systems (i.e. 95/NT) which are not
> really suitable for real-time work with a short period). The Linux version
> could be coupled to an RT-Linux task through a custom C-interface module,
> so I guess it could make a reasonable, albeit expensive, front end.
>
> I have used it for a few straight acquisition projects and found that it
> was just 'ok' - I did not find graphical programming to be faster or
> better than C (especially if it was used to read older binary data files
> - I found building "structures" somewhat painful), and you lose easily
> parsed text. I also did not find that it was easy enough for
> non-programmers to use, which was an initial selling point. Programming is
> a skill in itself, the tools don't create programmers from non-programmers
> no matter how pretty they are.
>
> The graphical controls, or widgets, are quite pretty though; I have used
> the NI Component Works library on NT/95 just to get those pretty widgets.
>
> There has been talk recently on the llp list and elsewhere of building a
> better LabVIEW-like (but non-graphical) system for Linux. I believe Tcl/Tk
> was being thrown about as the top-level programming interface.
>
> > If there are other easy to use graphical display builders or libraries out
> > there I would like to know.
>
> Many projects given here have used the much ballyhooed Qt library from
> http://www.troll.no/ - this library is used in some example programs from
> Victor Yodaiken's lab (Bill Crum's examples?), I believe, and David
> Christini employed it as well. It is very nice. Qt is now sort of open
> source, and free for non-commercial software, it is the basis of the KDE
> project.
>
> I have taken to using FLTK (fltk.easysw.com) which is LGPL'd and cross-
> platform between Win9X/NT, Linux, and SGI. It has a few nice widgets
> (look at the 'valuators' - especially the roller), and is under active
> development. It's big advantages are in its OpenGL support and the fact
> that it is a small static library - the execs are small and distribution
> is mindless.
>
> Other folks on llp have used Tk with BLT to handle the GUI
> (http://www.scriptics.com/).
>
> None of these toolkits contain the variety of pretty widgets from National
> Instruments. On the upside, all of them are open source in one sense or
> another, so there is less of a problem with vendor lock-in or
> inflexibility. They are all cross-platform in some sense as well, although
> Tk is the only solution which excels in this area (Qt will cost $$ to
> move back to Windows and there is no Mac support; for FLTK, Mac support
> is "in the works" but is not yet available).
>
> My opinion on LabVIEW (and by extension Visual Basic) is that it is great
> for small projects and prototyping. The downside (of both) is that they
> are relatively difficult to interface with outside code, can be difficult
> to maintain as projects grow, and they lock you in to a proprietary
> technology. You say that there is an educational discount for LabVIEW, but
> my copy of 4.0 still ran over $700.00, If I recall correctly, and to setup
> the same code on all of the researchers' desks would cost a mint in
> additional licenses. The runtime kit did not seem to be an attractive
> option either. Either way, in the end, you pay.
>
> -Don
Best regards,
Reg
Dr G R Dunlop, Dept Mechanical Engineering, University of Canterbury, PB4800
Christchurch, New Zealand
[EMAIL PROTECTED] ph ++64 3 364-2386 fax++64 3 364-2078
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/