LabVIEW
Is using Labview GUIs unprofessional?
Solved!
@theking wrote:
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.
That probably tells us more about the manager than about LabVIEW. 😮
Obviously, he is very misinformed. Maybe you can point him to this link right here..
There are two "speeds" that are important:
- Execution speed: LabVIEW is entirely comparable to other high level languages. Since LabVIEW can more easily execute code in parallel, It might require enormous time and efforts in text based languages to match LabVIEW in this regard. LabVIEW wins!
- Develoment speed: To develop a fully working, feature-rich program is significantly faster in LabVIEW and the advantage is even bigger once you include embedded and FPGA targets. A higher development speed directly translates in significant cost savings to the company. LabVIEW wins!
And yes, LabVIEW can be used to create UIs that look very professional. JKI has been mentioned (examples), but there are many more. You manager might have run across them numerous times without even recognizing that LabVIEW is under the hood.
@altenbachYou manager might have run across them numerous times without even recognizing that LabVIEW is under the hood.
This is the problem right here- bad LabVIEW GUI's are VERY obviously LabVIEW, but good LabVIEW GUI's are (frequently) indistinguishable from other good GUI's. This is a prime example of sampling bias 🙂
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. However, I cannot think of a language that more naturally takes advantage of the multi-threading capabilities of modern CPUs.
Actually the problem is slightly different. As pointed out before, LabVIEW has a low entry point, (the "See mom, no programming needed" slogan NI marketing sometimes uses). And it is very easy to create a program that actually works despite not having any formal computer programming knowledge. Never mind that those programs are often clumsy, inefficient and only work when you tickle their sensitive parts in exactly the right order.
If such a programmer attempts to do the same in C or even one of the more high level languages out there he will most likely end up with a big pile of crap that will never do anything else than frequently crash at the earliest possible opportunity.
But this does by no means mean that you can NOT write high performance, professional and user friendly applications in LabVIEW, IF you apply the same engineering discipline that you are almost required to have in those other environments!
@Gregory wrote:
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.
That was only true for a few of the early cross platform tools like the Mobile Toolkit to target Windows CE platforms or the ARM toolkit to target specific ARM SBCs. LabVIEW uses internally a directed graph to represent its diagrams. This is then fed into an engine that applies various transforms for optimization and then in old LabVIEW into an in-house made assembly code generator that generated equivalent code than what a C compiler would generate. It was in many parts about the same speed execution wise than C but had a few problems:
1) For each new CPU target NI needed to create a new assembly code generator from scratch up. This is a painful and time consuming process.
2) NI could not really compete development wise with the combined power of Open Source GCC developers and other C compiler developers in terms of optimization advances.
That led to NI changing the entire backend to use LLVM instead. You can see here more about the current compiler backend in LabVIEW. The important point here is that LabVIEW does directly generate and then execute compiled code and as such is very competitive with any other compiler using LLVM as backend. The advantage of LabVIEW is that dataflow programming lends itself much better for multithreading operation and the optimizer that translates a LabVIEW diagram into the intermediate LLVM input has to do less of work than an optimizer that must translate an inherently sequential souce code representation into a compiler sequence that can be properly parallelized.
@theking wrote:
He says that Labview is very slow and nobody uses Labview in production settings. He also thinks that sending customers Labview GUIs is unprofessional.
Bad code is always slow, as already mentioned. As an example i inherited a program that read a simple text file and created some control arrays from it. For a 100k line file this took ~45 secs, and it was due to a badly chosen line extraction tool. Bascially just changing this and removing some locals to shift registers i got it down to 2s including file read.
The LV GUI can look boring but it's easy enough to use System Controls for a much more windows standard look to things. However, as already mentioned, it's not unprofessional as many companies do use LV in their production and development, as Volvo.
/Y
@NeilR wrote:
@theking wrote:
... 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.
NI Marketing are you listening?
Maybe the boss needs some more brochures with "no programming required" printed in glossy format. 
I was going to add a </sarcasm> tag, but I decided against it.
