07-07-2005 12:27 PM
The system called the Suss PA 200 & NI waveform generation test suite:
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.
Trio-Tech 8” thermal chuck: GPIB interface to control temperature and PID control to maximize response time.
34401A Digital multimeters: Required for current and resistance measurements there are 2 34401A’s both with GPIB interfaces.
3646A programmable power supply: Required to provide proper power sequencing. The 3646A has a GPIB interface.
National Instruments PXI-1042 chassis with MIX-3 interface:
5 HSDIO 6552’s mixed signal FPGA based 20 channels with simultaneous acquisition/generation, with per card acquisition/generation voltage control.
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.
1 NI-2503 4x6 switching matrix: Required to perform resistance and current measurements.
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 Advanced Illumination S6000 strobe controller: Required for off axis illumination system. RS232 interface.
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.
1 Agilent 33120A function generator and FLC Electronics F20ADI amplifier to perform VI transfer characteristics
07-14-2005 03:55 PM
07-14-2005 06:56 PM - edited 07-14-2005 06:56 PM
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.
Message Edited by Ben on 07-14-2005 06:57 PM
07-14-2005 08:08 PM
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
07-31-2005 01:45 PM
08-24-2005 12:25 PM
08-25-2005 10:13 AM
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!"
08-25-2005 12:45 PM
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.
08-27-2005 03:06 PM
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
08-28-2005 07:20 AM