LabVIEW

There are other graphical programming languages?

"

OK, but I am limited in what I can reveal.

 

A large US government contractor operates a lab where advanced research is taking place. Years ago someone "in-house" developed the two applications using HP VEE because 1) They knew VEE and the applications used a big rack of HP hardware.

 

Since that time the original developer "moved on" and the two stations remained in use. Meanwhile, we (my company) have been busy training all of the in-house developers in LV and all of the add-ons.

 

The lab landed a big project that required they increase their throughput to support the associated research. Since the original devloper was gone and the facility had purchased a site license for LV they came to us to replace the two original applications and then adapt the code to be used with a robot (to move the probes around on the wafer) and one more version that scaled up the size of the widget.

 

I should also mention that the performance of the HP VEE version suffered from what appeared to be a "single threaded implementation". Durring critical phases of the test, the application would competely forget about updating any of the PID loops and a great deal of time was lost waiting for the application to re-acquire control of the process. I do not assign this short-coming to VEE but to the design implemented.

 

LV is by its very nature very adaptable to multithreading. The last version of the application required 4 PIDs be maintained while monitoring testing and recording.

 

I think that is as far as I can go without revealing the customer or the nature of the widget!

 

Ben

Man, if I did not know better, I would swear that was those two pig systems named after the RCA dogs (Nipper and Chipper) that ended up in Sunnyvale and Lockmart in the Satellite division for RF payload testing, except those were scrapped years ago, cause they were junk.  Maybe you inherited?  Just joking, I would not have wished that on my worst enemy!!

I've got my own VEE story. Several years ago, I was hired to develop some LabVIEW software by a company that will remain nameless (sort of). I was given a cubicle and a rack of test equipment. It got a little strange because right around the corner was the development team for VEE. Not a team developing in VEE but the team that wrote VEE (see what I mean about sort of nameless). Swapped some stories and a few methods of doing some tests. At that time, VEE was not compiled and it took at least an order of magnitude longer to do some analysis routines in VEE. I was also approached and asked if I would like to switch from being a LabVIEW Alliance member to doing VEE programming. Doing a little market analysis, I determined that I would probably starve because of the lack of VEE users. I understand that VEE has since improved it's execution speed but it's market share is far behind LabVIEW. I've seen some figures comparing how long it takes to develop a LabVIEW program for GPIB instrument control versus one in VEE. One in particular seemed to be biased as the study was financed by Agilent but the end result seemed to indicate that an experienced programmer of either would take roughly the same amount of time. The problem is, there are many applications that VEE would take much longer or just be impossible to do. It does not have nearly the number of add-ons that LabVIEW does (try running VEE on a PDA or a real-time system or doing vision). It has hardly any native instrument drivers (they mostly use IVI or plug&play DLLs). Third party DAQ manufacturers will often have a LabVIEW library written and seldom one for VEE. These are the important factors for me and I would guess for the majority of users.