[FRPythoneers] Re: VB/Python article....
J. Wayde Allen
wallen at its.bldrdoc.gov
Wed Jun 6 11:58:01 MDT 2001
On Wed, 6 Jun 2001, Ferdinand Schmid wrote:
> > language that they perceive as being textual. The current rage in
> > the our Labs is National Intruments Labview
> I used that in the early to mid 1990s and wasn't impressed at all.
> Coming from C it took me longer than I liked to learn G (Labview's
> programming language). It also was way too slow for my taste at the
Yes, well there is a reason you and I are over here on the Python list
isn't there <grin>.
That is one of my quibbles with the Labview game. As long as you have a
standard digital voltmeter that someone has already created a Labview
module for, and as long as you want to process and display your data using
one of the "canned" routines, then you simply drop the relevant icons on
the screen and draw lines between them to make it work. That is what gets
most people hooked. As soon as you need to do something that is new and
unique, and that is kind of the whole point of research, then you have to
develop your own modules. That means programming. Once this condition
occurs I don't think it makes sense to do this new development in a highly
We had (and still have) enough trouble here with the old legacy Rocky
Mountain Basic code when HP announced that it would be supporting the
language anymore (that has kind of changed since), and that was with a
textual "Basic" code. I shudder to think about what happens if National
changes focus, discontinues their product, or changes the underlying
constructs. I would rather use a more open and mainstream language
recognized by more than just one company.
> At my first job after graduate school I had to learn VB and implement a
> lab control and DAQ system in VB (VB 4 at the time). The reason: We
> could only get drivers for our hardware (some IEEE4888 bus card and
> several plug in daq cards). It seems that until very recently, when
> lots of daq hardware became TCP/IP enabled, we were often slave to the
> hardware vendor choices of programming environments.
Yes, and in a sense we still seem to be kind of slaves to the vendors on
this. I once tried to contact a vendor and get the raw programming
information. They weren't too forthcoming. VB was certainly an option
since drivers were available. We ended up building the RF power
calibration instrument control systems at NIST using VB for the instrument
control and data acquisition. On the 1 kW calibration system I wrote the
uncertainty analysis routines in Perl, and started working on a program to
compute equivalent generator reflection coefficients in Perl. That is
when I ran into the problem of solving a system of linear equations of
complex numbers. That was problematic in Perl, but is very easy to do in
Python. I've been kind of hooked on Python ever since.
> So let's hope that Python becomes mainstream - I really don't like
> having to go back to Windows over and over again to work on VB projects.
No kidding! In my area one thing that would help would be the development
of a solid instrument control library or module. Something like the GPIB
(IEEE488) Perl module <http://www.mock.com/gpib/index.html>. For the most
part, there seems to be relatively little Python support for data
acquisition and control. I've yet to turn up much of anything like this
for Python at either SourceForge or the Linux Laboratory Project
<http://www.llp.fu-berlin.de/>. I have recenlty be in contact with a few
other people interested in Python instrument control, but I don't seem to
find the time to experiment much with this.
(wallen at its.bldrdoc.gov)
More information about the FRPythoneers