A few weeks back, I sorted out a second contact to work on alongside the cBAM project. Unfortunately, the nature of this project means I can’t be as open as I would like – for now at least…
However, this week a problem arose in my new project that I am also dealing with in the cBAM project and I feel it needs sharing.
In both projects I need to develop some software to run on a PC as a user interface (UI). There are some differences between their requirement, but essentially they both need to run on a standard lab computer (if such a thing exists), have tons of functions, and most importantly – be intuitive and clear. Easy!
This led to an intresting dilemma for me – do I develop something in Python or Labview? I have experience in both – I’m a little more proficient in Labview but from a skills point of view, I’m perfectly capable of making this work using either coding language.
As a little intro for people who don’t have a clue what either language is, the cartoon below should make it pretty clear. One is a line-by-line language, the other looks like a FisherPrice drawing program for kids.
Fisher Price like Labview (left) and line by boring line Python (right)
I tend to find that Labview is great for easy to use interfaces but Python is open source and has a lot more community support. I honestly couldn’t make a decision.
So to help, I wrote myself a little pros and cons list for using each language, which I hope might also guide anyone else thinking about using either of these programs.
Labview
PRO
- Drag and drop interface
- Plenty of existing GUI widgets
- Program doesn’t fail because I forgot to add a ; to the end of a line
- Lots of debugging options
- One click compiling into applications or installers
- My colleague can read Labview code
CON
- Interface looks like it was made for a 3yr old
- Any UI made in it looks like every other Labview program
- Debugging feels like you are tracing a spider web
- Resource heavy (process and memory use)
- Developer edition cost is frankly nuts £3990
Python
PRO
- FREE! which is exactly £3990 less than Labview
- Platform independent ( I can compile it into any language, including Raspberry Pi)
- Obsessively helpful support community
- Having pages of code on my computer screen looks hardcore
- Thousands of free packages to add complex routines that I barely understand
- Very resource efficient
- There’s a Python expert sitting at a desk about 4m away from me
CON
- Making a good user interface requires a LOT of work
- Most UIs look like 90’s throwbacks
- Debugging is 75% guess work, 25% magic powers
- Spelling errors = bugs; which for a dyslexic is painful
- Version changes can break everything
- My colleague hasn’t the faintest clue what I’m sending him
.
So because both packages need to be extra user friendly, I’m going to have to stick with the FisherPrice look-a-like Labview. I just wish someone would hurry up and develop some easy to use pretty UI builders for Python!
25 Comments
Andy · 17 May 2014 at 06:42
Hello,
Good comparison between both.
I think though you forgot to mention Labviews main strength, the easiness to control instruments like voltmeters, signal generators etc, if the need shoud appear.
Elim Myers · 22 May 2014 at 02:13
Do you know about Python development with Qt -Qt designer?
http://www.youtube.com/watch?v=vQixM9TTUyU
http://qt-project.org/doc/qt-4.8/designer-manual.html
Matthew (@MCeeP) · 22 May 2014 at 09:28
No, no I did not!
That looks very intresting, I may have to do a Labview vs Qt Designer
Andy · 25 May 2014 at 10:36
It looks as a good option for creating simple buttons and indicators for the ones already using Python or for companies with smaller budget.
Nevertheless Python still have many years of development before something like this can be done:
http://www.youtube.com/watch?v=bFqvzMkRwpA
bc · 5 July 2014 at 13:48
This would be easy to do in python (speach recognition using the dragonfly library, UI using PyQt and hardware control using whatever interface you need – serial, parallel, ethernet, usb, GPIO). The bonus with using python is that you’ll still be able to understand the code in six months time. Oh, and the UI won’t necessarily look like a crap labview UI.
Albert · 30 August 2014 at 17:04
Then just do it yourself and send us the Youtube link. Hope the slow speed of Python wont be a problem for the robot reactions 😉
Matthew (@MCeeP) · 31 August 2014 at 21:06
*gasps*
How can you say Labview UIs looks crap! I mean literally every UI in labview looks exactly the same (and grey) and we can’t all be wrong!
Pancho · 30 November 2016 at 23:27
Be able to understand the code in six months time? Hell, I’ve looked at my own code 2 months later and I have to take a minute to process as to why I did certain things. However, with good comments on your code I reckon you wouldn’t have problem.
For GUI’s though, I’d go for Labview. There’s a way to change colors and customize objects. You can even add pictures onto objects if you want. The grey is just the default. You can change this. The Qt-Qt design is no different process than you doing UI via VBA in Excel, in fact, the interface even looks the same.
Rice · 27 August 2014 at 12:27
“•Debugging feels like you are tracing a spider web”
That happens only when your code is a spider web, which is very usual with the people who think that a graphical programming language like LabVIEW does not need any effort to learn clean coding.
And yes, LabVIEW is good for things which have to do with instrumentation or other hardware interaction and not necessarily for general-purpose programming. The GUIs here are thought mostly for internal usage at an assembly line or so, not for an end user which will be upset because the program does not look fancy. To create a GUI use Qt, TK, Visual C or any other tool thought for that purpose.
King · 30 August 2014 at 16:36
Mr RIce,
Whether Qt, TK and Visual C are better for making GUIs I don´t have enough knowledge to eiher deny or agree right now, BUT Matthew’s question here was about Python vs Labview. He can both those languages.
Matthew (@MCeeP) · 31 August 2014 at 21:05
True, python and labview are the limits of my knowledge. If you gave me Visual C I’d probably assume it was some kind of vitamin supplement for my computer 😛
Mark · 7 October 2014 at 14:43
I too preferred LabView for a long time because of the gui – until i came across wxFormBuilder.
It uses drag and drop to create the window visually, and then generates the code to be copy/pasted for use elsewhere.
http://sourceforge.net/projects/wxformbuilder/
Tibbles · 29 January 2015 at 06:54
In terms of using Python, I found the PAGE tool ( http://page.sourceforge.net/ ) is painfully easy to get started with. The callbacks make sense, and the generated code can be expanded very easily. I like to use Python for my general purpose office automation (along with AutoHotKey), and doing stuff on my Raspberry Pi.
*Disclaimer* I work for NI sales and I fucking love LabVIEW.
If you’re doing a test and measurement application, do yourself a favor and use LabVIEW. If you’re doing something else, don’t use LabVIEW. If you have a lab that wants to use both, use TestStand and mix and match. There’s also LabWindows CVI is you want to dip your toes into C… maybe you like C#? We have a module for Visual Studio. Do you want to run your MATLAB code in LabVIEW? We have… *sigh* LabVIEW rocks for what it was designed to do.
Diamond Tredspane · 21 January 2016 at 18:15
I’ve done plenty in both Python and LabVIEW for years, and I can tell you there’s a place for either, as long as you don’t care about UI. When I want a pretty (ok, customer-facing) UI, I use Visual Studio (C++, C#, or Basic), but when it’s in-house, I pick between Python and LabVIEW. If I have to interface with instrumentation, especially oscilloscopes, logic analyzers, signal generators, spectrum analyzers, pressure sensors, and PID devices, LabVIEW is hands-down my language of choice. If it’s a quick (both to come up-and-running and to generate test results) or small (no large overhead), or generic-testing application I need, I develop in Python without hesitation. So, honestly, there is no comparison (apples – oranges) because they both have their place. (I work in the gas / oil industry as a software developer.)
Lucy · 20 July 2016 at 01:19
Great article but…..What version of Python are you using that requires semicolons?! It’s the greatest thing I love about Python, compared to C++. Also, unless you take classes, work for NI or invest endless hours into studying Labview, it’s very difficult to program. It becomes a rat’s nest a few levels deep and is counter-intuitive.
I admit it’s a breeze to plug in a TC and have a nice chart on your screen, but £3990 seems a little steep for something that simple 😛 Also, the additional equipment starts to add up on your bill. By a lot.
IMO, I appreciate LabVIEW’s potential but I choose to go with Python because it’s easier to learn, extremely affordable and (like you mentioned) there is a ton of support.
Davee · 9 September 2016 at 17:22
Whatever happened to the good old days when all NI instrumentation came with (simple?) drivers so that you could write your test & measurement code with some flavor of C, and use any other tool (if your ‘C’ tools weren’t up to it) to make the user interface. Much simpler, *and* it built on the strong coding skills of developers (rather than trying to push folks to learn how to program [well] with pictures). Okay… programming with pictures isn’t really all that bad, but I’d rather stick with text based programming like every other programming tool I use works with, and have free drivers than have to pay $1000’s of dollars to have a proprietary, very narrowly focused programming environment that [allegedly] makes it easy for “non-programmers” to be able to write (usually simple?) test applications. Let the non-programmers use LabVIEW, but let the rest of us have free drivers so we can make NI hardware work easily with the same tools we already use every day.
PyMe · 29 December 2016 at 17:34
Why didn’t anyone suggest PIVISA? I’ve used python and PIVISA to talk to usb instruments. Note I didn’t say IEEE488. Get NI VISA installed and do python. I talked to scopes, function generators, power supplies. You don’t have to spend a fortune on cables. You can choose any GUI tool that is available.
PyMe · 29 December 2016 at 17:51
Sorry PIVISA should be PyVISA. I guess I had raspberry on my mind.
Matthew (@MCeeP) · 29 December 2016 at 17:56
Because PyVISA is as about as intuitive and simple as wrestling a bag of pythons into a much smaller bag.
While it works in theory actually making it work is a whole lot more frustrating than using the labview drag and drop equivalent.
Zhe · 9 December 2019 at 12:59
“more frustrating than using the labview drag and drop equivalent”
LOL. Connecting all those 1px wires and trying to guess what each control and socket means certainly is not frustrating at all. /s
Vince West · 31 January 2017 at 02:59
I have never used LabVIEW so I can’t really offer an informed opinion, but I have a particular workflow that works quite well in Python and I wonder if it could be easily replicated in LabVIEW, or I wonder if the integration of python into labview would provide the best of both worlds.
I have developed several gui applications at this point for doing materials analysis using measurements from a network analyzer. In python, using ipython notebooks has allowed me to protoype quite nicely the algorithms for converting network analyzer measurements into materials data, which can be quite mathematically complex (pun intended). The prototyping code can be more or less dropped in as is to the broader python module that my work has grown into. Using pyqt, I can create a rich set of gui widgets, and because it is object oriented the gui’s can simultaneously process many measurements and many data sets, represented in ListWidgets with drag and drop capability allowing me to process and compare the datasets in different ways on the fly. pyqtgraph is a very rich plotting library providing very nice interactive graphing capabilities so that I can inspect the data, do the materials analysis and inspect the results all within the same application and for many measurements simultaneously. I can also do non-linear least squares analysis within the gui, and again those routines use scipy numerical analysis and were prototyped in the ipython notebook. The communication with the instrumentation is more or less the “easy” part as pyvisa is actually quite simple. The difficulty is the need to work with the instruments using lower-level SCPI commands, rather than higher level and somewhat standardized functions that probably are found within LabVIEW. All said and done, if one has the right development tools, I am pretty impressed with what can be achieved in python. Focusing on the science aspect of things, and having done a little bit with C, I am certain that the whole process is faster than what could be achieved with standard compiled languages, though it is probably less capable if things scale too large. If you are running a major web-framework with a million lines of code, C# is probably a better choice, but for a sophisticated 10,000 line scientific application, python is great. Python gui applications can be quite sophisticated (Spyder is an instrospective IDE complete with integrated console for example written in pyqt). They can grab information on the web, and interact with SQL, nicely handle zip file archives and you can even implement computationally intensive routines with just-in time compiled code that looks a lot like normal python code. Can you do all that with LabVIEW (serious question, I don’t know the answer).
Nonetheless I assume (I don’t have experience with it) that if the main goal is working with many different types of instruments and collecting data, that LabVIEW probably has been polished to do all of that quickly and robustly, whereas in python, the high-level libraries for working with instruments leave a lot to be desired.
Matthew (@MCeeP) · 31 January 2017 at 07:44
Hi Vince,
The answer is a very clear unequivocal, maybe.
All of the data process and dataset handling you talked about is very doable in labview. The data communication stuff is a little more difficult because I don’t know what is/isn’t supported off the top of my head. I know that the SQL stuff is indeed supported quite well but SCPI I’d have to google more to give you a clear answer
From what your saying though you already have something that works well in python, i’d stick with that. Yes it is probably quite possible in Labview (nothing stands out as a problem really). But if you’re happy with Python I’d stick with that 🙂
Piotr Kruczkowski · 13 April 2017 at 16:51
Or you can try this https://forums.ni.com/t5/LabVIEW-APIs-Documents/Open-Python-Interface/ta-p/3612981
Its an Open Python Interface toolkit for LabVIEW
mike · 22 March 2018 at 06:02
well, you helped me at least
I want to help my highschool to achieve a robot, and of this, they want to take a labview..
i’m still concerned, afterall it actually looks like those 7year old coding programs google funds..
but in the otherhand, when you look at it, it seems far easier, nobody but me in my highschool knows python, and labview allows the people to actually understand what i’m making..
my serious concern was that what might happen a glitch in the labview program itself which could cause a problem. and moving the whole code into python would be the solution..
gladly I found out it’s actually possible..
at least I hope I got it right
java is not much of a difference from python as well.. (in syntax)
so java or python, both possible
and labview knows how to transfer to each of them
disclaimer: luckly for me, there is a sponsor (high school) so i won’t have to worry much about the prices
Adrian Keister · 7 August 2018 at 18:22
Why not get the best of both worlds? My company, Wineman Technology, an NI Alliance Partner, has put out TestScript, a Python/LabVIEW connector which is free and source-released. You can download it here:
https://www.winemantech.com/products/testscript-python-labview-connector
You can control Python from LabVIEW by telling Python to execute scripts and, what is more (and not possible with other approaches) you can automate LabVIEW from within Python by defining functions can calling them from a Python script. So you get the ease-of-GUI-development and instrument connectivity LabVIEW offers, with the scripting ease Python offers.
Enjoy!