Labview or python?

Obvious PythonA 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.

Labview vs Python
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.



  • 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


  • 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



  • 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


  • 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
I really want to develop the programs in Python – it’s got much better longevity and the more I use it, the better I’ll get but, for preparing UIs it’s… well… terrible. I know I can use packages like TKinter and WXpython but even these only make a UI possible, not easy or pretty.

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!

21 Comments for “Labview or python?”




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




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:



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.



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 😉



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.



“•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.



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.



In terms of using Python, I found the PAGE tool ( ) 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


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.)



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.



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.



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.


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.

Vince West


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.


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 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *