I started programming with LabVIEW 5.0 in 1997. I took a basic
and advanced LabVIEW course. My first application used two
cameras, 14 pneumatic fingers, a DMM, GPIB programmable power supply,
and one DAQ card, I think. It was less than 50 VIs to test two
oven controls simultaneously in under 24 seconds. There was no
requirement for revision control or documentation.
The largest application I support now is 176 VIs with very stringent
documentation and revision control. It tests airplane parts, and
the test time is about 45 minutes. I did not write the program,
but when we received it from the vendor only about 25% of it actually
worked as specified. I spent almost 6 man-months making it work,
so I guess it's "mine" now. It would be simpler if the original
programmer had used a state machine, but he called child processes with
server functions instead. It works now, but changes are rare
because it literally takes hours or minutes to fix a problem, but days
to revise the documentation.
Another application runs a 22-hour test in an environmental
chamber. Up to 6 test articles run simultaneously. That
application is 76 VIs, and includes VIs made exclusively to test other
VIs. It has a "simulate" feature that allows running the program
about 30x faster for debug purposes while still retaining the "real
time" DAQ. Both of these applications are subject to Measurement System Analysis, a mathematical method of determining test effectiveness.
The program I'm developing now is over 80 VIs and counting. It
will run two endurance tests for almost a year. The two test
articles have to run simultaneously and independently, yet have a
common interface with both automatic and manual modes. The system
architecture forces the test program to be that way. There will
be two very large test stands, one indoors, the other outside.
One stand has 8 tons of steel weights to move up and down. The
other has a 50Hp motor I will program to "simulate gravity." I
also built simulation into this program, because no hardware or test
articles will be available for some time.
No, I'm not too worried about running that long with a Windows OS
(2K). I have another endurance application that's been running
almost two years without a problem. The only time the computer is
turned off is when power fails. LabVIEW programs can be very
stable. And also, "No, I don't have great affection for Microsoft
either."
My first programs were relatively unstructured and not well
documented. However, you learn very quickly that you don't
remember what you did or why. Document those babies!
One very helpful book is Conway & Watts A Software Engineering Approach to LabVIEW.
State machines and messaging make programming large apps much
simpler. Large applications can cause huge problems if you don't
spend the time up front to plan a reasonable system. I have a
background in circuits and mechancal design. Software design is
similar. Know the overall function and break it up into smaller
testable pieces. Do that in your head first.
I'm impressed with the documentation capabilities built into
LabVIEW. It's obvious someone thought seriously about it. I
like the graphical approach. I programmed in PASCAL and
assembler, and structure in LabVIEW is so much easier to find than in a
text language. I don't have the professional versions, but have
made utilities of my own to extract revision data from VIs and export
hierarchies to EXCEL files. I don't know if present-day advanced
courses teach this aspect of programming, but they should.
LabVIEW started as a way to get measurement data into a computer, bu
