market share

[mrbean]

I can't seem to find anything on the web that shows me LabVIEW's market share against its graphical programming competitors.  Can anyone point me to some statistics.  Thanks.

[PaulG.]

There are other graphical programming languages?

[mrbean]

I'm doing a trade study between LabVIEW and Agilent VEE.  I was wondering how industry rates the two.  Market share was one of the pieces of information I wanted to use.  If there are existing trade studies, I'd like to see those.

[Ben]

"

There are other graphical programming languages?"

I wish this was not so!

I just wrapped a 3 month project that required re-writting 2 HP VEE apps and then using those as the basis for two more. I did get alittle tired of hearing "well in the VEE code..." while the first two were being tested.

Ben

[mrbean]

Is there any way you can share any information (metrics, justification, trades) from that project.  For example, why did you decide to re-write the VEE code in the first place.  I'd love to know more about your findings.

[Ben]

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

Message Edited by Ben on 10-13-2005 02:56 PM

[PJS]

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!!

[Ben]

Nice guess Paul, but no prize for you!

I would like to mention that I have noticed your recent contributions here and would like to welcome you to our little party.

Its nice to have a CLA around when you need one

If you have not noticed previously there are two areas you may want to look at.

At your current rate you should show up as one of rising stars in the E-List found here

http://forums.ni.com/ni/board/message?board.id=130&message.id=1861&jump=true

and in the breakPoint

http://forums.ni.com/ni/board?board.id=BreakPoint

you will find a place where the phrase "1 can not be represented in binary" (Copyright Christina Altenbach) will get a laugh.

Ben

[Dennis_Knutson]

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.

[tst]

Paul, I agree with Ben that it's nice to have CLAs around, but I do have one (rude?) request - can you change your signature?

One of the things I like about this site is that their design is usually clear and makes it easy to understand where things are. Putting big, bold, red and blue text in the middle of it is visually distracting and disorienting.