LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Tell us about your large LabVIEW applications!

Hello Michael,


I have a brief listing of one of my projects below.  I do not know how many vi's there are but probably over 1000.  There are also applications written to visualize DDR DRAM defects with respect to their physical location on the die, waffer maps with this and other testing info.


The system called the Suss PA 200 & NI waveform generation test suite:


  1. Suss PA200 8” wafer prober with 6 DC servo motorized programmable axis, 7 with proposed motorized zoom lens and 2 communication links, (GPIB and RS232, both are required for testing) It should be noted that the SUSS motion controller does not comply to IEEE 488.2 standards and requires an additional GPIB controller in the test computer because it will not co-exist with the other instruments. Good and proper operation of this machine tool requires PID servo tuning especially as we continue to add mass to the microscope stages.

  2. Trio-Tech 8” thermal chuck: GPIB interface to control temperature and PID control to maximize response time.

  3. 34401A Digital multimeters: Required for current and resistance measurements there are 2 34401A’s both with GPIB interfaces.

  4. 3646A programmable power supply: Required to provide proper power sequencing. The 3646A has a GPIB interface.

  5. National Instruments PXI-1042 chassis with MIX-3 interface:

  1. 5 HSDIO 6552’s mixed signal FPGA based 20 channels with simultaneous acquisition/generation, with per card acquisition/generation voltage control.

  2. 1 NI-7811R FPGA based digital only acquisition/generation system with 160 digital channels. Necessary for long term testing and future enhancement and flexibility of the testing systems capability.

  3. 1 NI-2503 4x6 switching matrix: Required to perform resistance and current measurements.

  4. 1 NI-1428 camera link interface: Required for imaging system. This card will be replaced with a PCI version running in another computer due to bandwidth limitations

  1. 1 Advanced Illumination S6000 strobe controller: Required for off axis illumination system. RS232 interface.

  2. 2 TDS 3054 and TDS 3014 Digital oscilloscope: Required for analog assessment of signal integrity and VI transfer characteristics. This scope has GPIB or Ethernet interfaces and a Labview application to store waveforms on the network.

  3. 1 Agilent 33120A function generator and FLC Electronics F20ADI amplifier to perform VI transfer characteristics


Message 71 of 105
(4,666 Views)
In my experience I think it's not the size of the application that matters, but the ability of a particular languague to solve highly complex and difficult technical problems with ease. For the latter LV I think is a good choice. Just imagine being able to control interferometric measurements and in turn being able to output results in the microscopic level (~1 microinch). That's a challenge that you can solve rapidly and easily with LV.
 
Otman 
Message 72 of 105
(4,705 Views)

Hi Otman,

 

I was originally introduced to LabVIEW by Dr. Jeremy Levy of the University of Pittsburgh.

 

He invented Apertureless Near-Field Scanning Optical Microscopy (ANSOM) which is capable of atomic scale resolution.

He did this of course, using LabVIEW.
 
Ben

Message Edited by Ben on 07-14-2005 06:57 PM

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 73 of 105
(4,697 Views)

Ben,

That's interesting. Most of my work deals within the microscopic scale using Helium-Neon lasers with wavelengths of 632.8 nm.

Unlike you though, my introduction to LabVIEW was strictly work related. Before my lab decided to standardize on LabVIEW, we used a variety of different languages and development environments. Actually, we had an open policy as far as which languages we could use. Our major/chief concern was to develop working software that would do the job reliably and consistently.

Otman

0 Kudos
Message 74 of 105
(4,507 Views)
Hello,

I am pretty new to LabView and DAQ. I want to measure a AC voltage and Current seperately generated from a single phase power supply range 0-120V AC using the DAQ card NI-PCI-MIO-16E4 and LabView 7.1. I also have the connector block CB-68LP and the connector wire. I dont have the pin diagram of CB-68LP and and any example VI from LabView doing the same work..  I also have Current Transducer CTL-101/100 and Signal Conditioner  CTA201P.

ANy help is much appreciated. Any VI or weblink supporting this is needed.

Thanks
0 Kudos
Message 75 of 105
(4,444 Views)

Hi Mike --

I am an EE and self-taught on LabVIEW: four years with Base package, one year with
Full Dev System (the event queue structure is worth it).

I have a body of control VIs (drivers, if you will) for the Microwave and RF test
equipment used in our shop. We design and manufacture LNAs, SSPAs, Frequency Converters,
Line Drivers, etc. I have used LabVIEW to automate many of the repetitive measurements
made by technicians and to calibrate and test our products in a variety of situations.

Among the ATE systems I have developed are two that have been particularly effective
in increasing throughput and uniformity of quality, and they are probably the "largest."

One system uses a PC with a GPIB controller card to control a signal generator, a power
meter, two power supplies, and an environmental chamber. The system controls the DUT
via RS-232 serial. A lot of data is acquired at a number of ambient temperatures and
DUT operating points. A unique set of calibration tables is created from this data,
loaded into the DUT, and then the performance is evaluated at a number of ambient
temperatures and DUT operating points. Failures are trapped, and audible-visible alarms
are sounded using automobile lamps, horns, and turn-signal flashers. As cool as the
whole test is, I get the most comments on the alarm. Go figure.

Another system uses GPIB to control a scalar network analyzer and a sweep oscillator.
Serial ports are used for the environmental chamber and up to three DUTs. An A-D I/O
card is used to control RF switches to multiplex the DUTs onto the scalar measurement
equipment. I built some custom shelves for the environmental chamber, too. Guess what
gets the comments?

LabVIEW is a marvelous tool for this work. GUIs are easy to build, modify, and explain.
Data analysis is great (I have used some of the built-in features, but I still do most
on my own, so any mistakes are mine, and so I don't forget how to do it). File I/O
is something I wrote routines for years ago, and I have not had to monkey with since.
Tests that take a long time save all data locally, then copy it to the LAN server at the
end. If the server goes down during a test, the test finishes normally except for the
backup operation.

Some problems crop up if I re-compile a program in a newer LabVIEW version, but far
more often, I have to re-work a program after a Microsoft Update. The change from
Win98 to WinXP generated some work. For example, the ability to control the RTS line
in real time, used for RS-485 2-wire serial comms, went away with Win XP. I had to
remove the INPORT function, and change to new RS-485 cards that had an auto-switch
feature in the receiver-transmitter.

Thanks for the opportunity to chat.

-- Paul

0 Kudos
Message 76 of 105
(4,241 Views)

I am a self-taught LabVIEW guy. Many good books on teaching yourself LabVIEW, but for good code structure I highly recommend reading "A Software Engineering Approach to LabVIEW" by Jon Conway and Steve Watts in tandem with whatever means you are learning LabVIEW. I have a C-Scan system written entirely in LabVIEW that operates motion control, DAQ, pulser/receiver, image analysis, the works ... utilizing state machine design and OOD and LCOD principles taught in this book. I have written nearly half of the 500-some sub vi's, but it's the easiest thing to maintain, improve and debug.

"LabVIEW Rocks!"

 

PaulG.
Retired
Message 77 of 105
(4,331 Views)

    The application I work with seems fairly large. There's over 400 vi's. About 75 megs. We rely heavily on NI data aquisition cards to communicate with our own hardware. Overall I'm pretty impressed with how easy some things can be in LV. The rest though seem fairly difficult. I do think LV is a great language for some, but it is very undocumented and trying to figure out what it does at times can be frustrating. Especially with how it deals with memory.

    To me LV seems very difficult to develop large applications. PLEASE correct me where I'm wrong, I hope there are ways to do some of these things that I have problems with. Multiple developers seems almost impossible to me, merging large files with many differences, and maintaining seperate branches of code in LV is far inferior to text based languages. The fact LV cannot have two VI's opened with the same name is a big drawback. How else can I look at old versions of code while working on new ones? I also just found out about LVDiff, thanks again.

    I'm not sure if I'm missing something, but my main GUI vi (about 8MB) has a large amount of controls/indicators; this makes a couple of things very difficult: When creating events, trying to find the control in the event window can take a long time. The variables are not in any worth while order(they seem to be in the order they were created). Can we at least sort them alphbetically? Same thing goes for selecting a local variable out of a list. If the list is long it can take quite a while.

    Another large drawback is with arrays and property nodes. Not being able to disable an individual control, or change colors, or... in an array of buttons/controls is devestating to my application. The fact all elements of an array have to have the same properties seem completely against OOP.

    The debugger with a large VI is just about useless to me. If I want to watch certain portions of code run, my computer almost locks up. Because labview tries to run everything in parrallel, when I set a breakpoint, then turn on the little lightbulb, it can take many minutes until I actually see my code run.

    Saving is also just as large of problem. It can take a minute to save my vi (I am running a p4 3.2G processor with 2GB of ram). The same goes with trying to open the property window of a control. It can take at least a minute at times. WinXP thinks the program is not responding. These things make developing very frustrating. I know I shoudn't have such a large vi, but how else do you make a large complex GUI?

    Some other problems I have; with variables, you can't cut/paste them. So your only option is to drag them around (mainly because selecting them from the list is worse and if they're hidden on the front panel I can't create them from there).  Again, with a large VI this can take some time scrolling around. Trying to keep the vi looking good takes more time than developing it.

    The endless amounts of crashing that occurs in LV is also a pain. The undo command has caused this one many times. The undo stack errases after a save and having undo crash the system, ouch. No way outta that one. Duplicating events also crashes the system pretty regularly. Things that don't really happen in text based languages.

    Enums/rings have also been a pretty painful. Because globals don't work efficiently, the only way to use enums is with constants. Once the constants get spread throughout the code, changing them is absolutely unacceptable. What's the better way? I know constatns are a huge NO-NO.

    I'm sure I could go on longer and I am well aware that some of the poor design in this system causes some of these headaches, but there also seemed like no other practical way out.

0 Kudos
Message 78 of 105
(4,187 Views)

Hi Mike,

I work with developing large test systems. The applications typically includes databases, server applications and quite a number of clients. We develop in a mixed enviroment using LabVIEW as well as Microsoft .NET. The clients are usually LabVIEW developed. Our base test platform has just above 5000 in-house developed VIs. Which is compiled with application builder to a single installation package (yes it takes some time).

For version management we use Subversion. To model and maintain documentation and code we use the UML modeling tool Enterprise Architect from Sparx Systems together with a in-house developed LabVIEW plug in for integrating the UML model with our LabVIEW code, managing both classes and "single" VIs. The code itself is a mix of GOOP code and "traditional" LabVIEW code. 

Regards

JOUL  

Message 79 of 105
(4,148 Views)
Hey all..
 
Im very virgin to this LabView thing so I kinda need your help..
 
1. How to datalog ecg signals acquired from a DAQ board?
2. How do i save the waveform to a binary file?
 
is there anybody that can help me with the programming...
HELP MEEEE..
 
Thnks in advance!
0 Kudos
Message 80 of 105
(4,410 Views)