LabVIEW
Is using Labview GUIs unprofessional?
Solved!
1. It is only slow if poorly programmed, just like C. Unfortunately, LabVIEW tends to have a lower entry point and therefore it is more common to see poorly written programs that work.
2. Again, depends on how they are implemented. I am actually currently looking at a HORRIBLE GUI that was recently written in C++ or possibly VB (it is colored like it was from the 90s). And I have seen some really good LabVIEW GUIs (give JKI a good look).
So it really comes down to being able to use the tools properly.
@theking wrote:
I am a test engineer at a high tech company in San Francisco bay area. I have been developing Labview automation routines for several years but mostly in the academic sector. I am new to the industry environment. I have had multiple arguments with one of the Engineering Managers about using Labview in final production tests on devices and on sending customers Labview GUIs to interface, control, and automate their tests and equipment with our products. He says that Labview is very slow and nobody uses Labview in production settings. He also thinks that sending customers Labview GUIs is unprofessional. He prefers GUIs written in C language.
I wanted to see what's your thoughts on that and if there is an article or a reference I can cite to convince him otherwise
I guess "nobody" includes major portions of the aerospace, transportation, medical and energy industries? I suppose you could make a GUI in any language that looks unprofessional, so I suppose you can do that with LabVIEW, also. The same thing with slow applications. The "problem" with LabVIEW is that it's a lot easier to produce crap code that is highly inefficient, slow and clumsy than with most other languages. However, I cannot think of a language that more naturally takes advantage of the multi-threading capabilities of modern CPUs.
Hi there,
You have brought up several questions that each deserve a thorough treatment of their own. However, I'm not going to give them justice and just give a quick blurb on each.
Using LabVIEW for final production tests
First off, there are a ton of companies that use LabVIEW in production tests. Some of the bigger ones that come to mind are Tesla and SpaceX if you want to name drop, but so do the companies I've worked at which range from <100 people to >2,000 people. Many people will use it in conjunction with TestStand to make it easier to handle test scripting with minimal change to the underlying code. But whether or not TestStand is useful in your situation will depend a lot on your product mix, resources available for learning, and openness to change. If your company is buying NI hardware as well, then LabVIEW is the obvious choice for production tests.
Sending LabVIEW GUIs to customers
It is still annoying that you need a ~300MB runtime engine to run even the simplest of LabVIEW executables, but besides this I think it is completely acceptable. Now, it takes a little effort to make a GUI not scream LabVIEW, but it can be done and there is an enthusiasts group on these forums. I like the look of most systems controls, as well as JDP flatline controls which you can get through VIPM. Also, JKI has a blog post on how to make custom buttons. Do not just throw buttons and graphs down with debug indicators everywhere, as that will be very hard for a user to figure out. Here is an example of a recent application I made which I think looks pretty clean (covered some stuff up for privacy):
LabVIEW is slow
I'm guessing your manager has not worked much with LabVIEW, or has worked a lot with poorly written LabVIEW code. As far as I know, the graphical code you see in LabVIEW is compiled into C before it is run. So it is not slow compared to C code, in fact it's exactly the speed of C code.
Maybe you will be able to change your manager's mind by writing great code and making impressive GUIs. But, I've found that most people (managers especially) who come in with the idea that LabVIEW is a gimmick or that it's impossible to write larger applications because there are wires everywhere, simply don't want to change their mind.
By the way, the bay area users' group meets quarterly, so you should definitely check it out and you can meet some other locals and see how they are using LabVIEW. (Link to BALUG in my signature).
- last edited on by
Content Cleaner
@Gregory wrote:
As far as I know, the graphical code you see in LabVIEW is compiled into C before it is run.
Completely FALSE. The graphical code is actual converted to a DFIR, which can then perform even more optimizations before compiling to direct machine code.
I think there is a better article, but I don't have time to go dig: The LabVIEW Compiler - Under the Hood
@billko wrote:
The "problem" with LabVIEW is that it's a lot easier to produce crap code that is highly inefficient, slow and clumsy than with most other languages.
The difference might be that a poorly written LabVIEW program still mostly works, but a poorly written C program does not even compile.
