Community Browser
Showing results for 
Search instead for 
Did you mean: 

LabVIEW and Python: Friends or Foes?

‎03-14-2017 09:00 AM
‎03-14-2017 09:00 AM

Python’s popularity as a programming language continues to rise, and the test and measurement community has begun to debate when to use LabVIEW and when to use Python.


28612_Python_LabVIEW_Diagram.pngTo answer this question, we spoke with Collin Draughon, one of our software product managers. He believes you shouldn’t have to choose between these two powerful engineering software tools.


NI: As a Certified LabVIEW Architect and a Python developer, do you recommend LabVIEW for certain tasks and Python for others?


Collin: The major difference between LabVIEW and Python is that Python was built to be a generic programming language while LabVIEW was built specifically for engineering applications that require test, measurement, or control. What this means is that LabVIEW excels at engineering-specific software needs, such as simplified hardware integration, the creation of engineering-focused user interfaces, access to built-in analysis libraries and domain-specific IP from the LabVIEW ecosystem, and complex timing representations.


On the other hand, Python is used across a plethora of domains because of its industry-agnostic offering. This has led to a vast array of libraries and modules for every kind of task. Users looking to build an engineering system that requires custom functionality from their domains or industries can often benefit from using both LabVIEW and Python together: LabVIEW to build out the engineering components and user interface, and Python to execute tasks in parallel like web dashboard building, machine learning, natural language processing, and so on. This gives users the ability to quickly build out engineering applications with LabVIEW while maintaining access to the vast ecosystem of Python libraries.



NI: Why should LabVIEW users learn more about Python and vice versa?


Collin: I often see code written in other programming languages be pulled into LabVIEW applications for a specific task or function. Over the past 10 years, Python has grown in popularity and expanded to offer hundreds of thousands of domain-specific packages for applications ranging from generating StarCraft II replays to modeling complex geophysical systems. LabVIEW users can take advantage of this Python code by integrating Python scripts into their LabVIEW applications.


Python users looking to build engineering applications can benefit from learning more about LabVIEW because of the tools LabVIEW offers to simplify common engineering tasks. Python is a generic programming language while LabVIEW is specific to building out engineering applications.


LabVIEW can greatly reduce a developer’s development time by optimizing the engineering-specific workflows they need to complete.


NI: How should LabVIEW developers integrate Python into their applications?


Collin: On Windows systems, my go-to method is the Python Integration Toolkit for LabVIEW by Enthought. We partnered with Enthought to develop a simple LabVIEW API that allows developers to call Python code in parallel with running an application. Using the toolkit, I can easily specify the Python script that I want to load into memory, pass it all the parameters for a specific function I want to call, call the function, and instantly get a response in LabVIEW from the Python interpreter.


If you enjoyed reading Collin’s thoughts on this topic, you can learn more about our Python Integration Toolkit for LabVIEW during this webcast that he’s co-presenting.



Trusted Enthusiast Trusted Enthusiast
Trusted Enthusiast

Call me pedantic but the comparison between LabVIEW and Python is a comparison of an IDE with a programming language.  That's not an apples-to-apples comparison.


I wish NI would be more careful about their awareness of these differences in general as it degrades the ability to have credible in-depth discussions with anyone outside of NI when NI itself doesn't take the required care with their terminology.

Member TheNIDragon

Hi Intaris!


I'm the Collin Draughon from the blog post and I completely agree with you! At the end of the day, Python is a programming language and LabVIEW is an ADE, or, application development environment. For anyone reading that's not familiar with the difference, programming languages simply express the solution to a problem whereas an application development environment includes tooling around a programming language to more productively develop, debug, and deploy your code. In the case of LabVIEW, this tooling would be the front panel, project explorer, application builder, debugging tools, software configuration management, etc.

To compare LabVIEW and Python at a feature level is silly - it's not apples-to-apples as you mentioned. However, when it comes to developers deciding what tools to use we often see the question raised "Should I use LabVIEW or Python?". While we can (and often do) jump into the difference between a programming language and ADE, the next logical step would be to separately compare the G programming language with Python and LabVIEW with one of the many Python IDEs/ADEs. In my opinion, this argument can often "lose the plot" as we start discussing low-level details, because, at the end of the day, it all comes back to the idea that LabVIEW has been built and optimized over 30 years to streamline the workflows and operations of engineers (which includes the benefits of G) and Python or any Python IDE/ADE has not.

As an example, you might have heard the argument that because LabVIEW uses a graphical programming language and not text-based like most other languages, it can be difficult for developers using C/C++/C#/Java/Python to pick up this completely new paradigm. But if you look at it through the lens of LabVIEW as an engineering-specific development environment, things make more sense:

  • The graphical style allows me to more easily develop parallel running applications - a common acquisition requirement for engineering systems.
  • For engineers, the graphical style also harkens back to how I would start designing my system - probably on a white-board showing logical flow, making it easier to transition from design to programming.
  • Instead of attaching all of my signals to variables, I can immediately see at what stage in my system a specific signal is at through wires and immediately probe for that value.

These are just a couple of the ways LabVIEW differentiates itself to make application development easier for engineers and there are many others we could discuss.

Apologies for the long post. All of this to say - I completely agree with you yet sometimes the discussion is simpler if we look at a tool's intended use rather than a tool's identity.

Thank you for the post and interesting discussion - looking forward to your reply!


Trusted Enthusiast
Trusted Enthusiast

I would suggest creating a User Group in the community (e.g. in the Partner Groups section) as others have done (e.g. Advanced Plotting Toolkit, which also uses Python under the hood). There is nothing about the LabVIEW toolkit on your website (or your search engine doesn't work), the only working link being from the LTN.

It is not clear to me how your license work for released executables including your toolkit. Can you clarify?