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

Re: 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?

Member sletrab

In that way you can connect LabVIEW only to Enthought Canopy witch is still Python 2.7. The current Python Version is 3.6 ;-(.

Member carrasquel

I am really angry about this, I don't know how to call it, interview or article, it seems that either the interviewer and the interviewee, despite their super duper Certified Architect, they do not have any other implentation or integration with Python that just embedded scripts, and only by using Enthougth and its 500$ toolkit, from one paid tool to another, it seems that the advantage of Python being open source is taken for granted. I thought that LabVIEW experts could come up with other idea of how to integrate both of these development environments/languages, but I guess I was wrong.

Where are the use of protocols for data exchage between both (real time, modbus, opc, sockets, http), where are the advantages of using Python and their third party libraries of Machine Learning to NoSQL database integration, or even just scientific and numerical analysis. The lack of information here is overwhelming.

I betting for this "article" being another way of advertising useless paid toolkits just to connect with other lenguage. I mean there is no need to, even if you want to just execute a fixed commands through a script, a simple Python pseudocompilation can be made with pyinstaller, and later using the CMD subvi for parameter exchange on LabVIEW could be made. But it seems that there is no effort in pursuiting this because its free.

If anyone has really struggles on how they can use Python with LabVIEW, I can show you how I created a Dynamic Simulator of a Gas Compression Station using Python as the calculation engine (Flow-Pressure Network, Thermodynamics) and LabVIEW as the SCADA.

Trusted Enthusiast
Trusted Enthusiast

@carrasquel: Please do. You can create a document or start a thread in the LabVIEW forum (but it runs the risk to be lost in the noise there).


I personally don't have a problem as a developer to pay for a development toolkit. The Enthought toolkit looks nice, but the fact that an executable released with it requires a license to be paid by each end user totally defeats the idea of using Python as a way to connect LV tools with an "open source" language. I dislike the Vision Toolkit (pure NI product now, but was purchased long time ago from a third party company - which I suppose is the plan of Enthought), for this reason: users (all academic) need to purchase a license from NI to use programs I develop and release for free... Talk about trying hard to discourage academia to use LabVIEW for developing anything beyond hardware related software...

As I tried to argue with Enthought after watching their webcasts, they lose potential customers with this policy. They haven't bothered to answer my email so far.

Member TheNIDragon

Hey carrasquel,


Super duper Certified Architect Collin Draughon here! I wanted to first thank you for your feedback - I truly appreciate your candor and honesty. I wanted to address each in turn but wanted to make a quick plug for which has a lot more information on NI's integration with Python beyond just the Python Integration Toolkit.


First off, I want to make it very clear that using the Python Integration Toolkit is not the only option available for integrating Python with LabVIEW. You mention the use of protocols and the CMD SubVi, which are great options - my buddy Piotr made some awesome videos on creating a TCP/IP server client architecture with Python and LabVIEW:

We also have an entire tutorial on using the System Exec VI with scripting languages here:

This doesn't even start to cover all of the integration options available such as the LabVIEW automation library, PythonVIEW by 3T, or LabPython, so please don't think that this is all the integration we have to offer.


I want to harp on that last one, LabPython, as a proof point for why the Python Integration Toolkit from Canopy is priced. LabPython started out as a great initiative to provide a nice way to call Python from LabVIEW, however, because of its architecture, caused a lot of installation issues, was generally difficult to use, and lost interest from the community - leading to the somewhat stagnant LabPython we have today. A lot of the hard hard work that the Enthought team put into the Python Integration Toolkit was to create the scalable architecture necessary for what is really the best way, in my opinion, to call Python from LabVIEW. This doesn't take into account all of the other costly things associated with a software toolkit - support, updates and maintenance, compatibility with different LabVIEW versions, testing, deployment (which they put an amazing amount of work into to manage Python packages), and many others.  Additionally, purchase of the toolkit gives you a copy of their awesome Canopy Python development environment. I guess it didn't come out as much in the article as I intended it to but the Python Integration Toolkit does a LOT more than just call a simple Python script. You are absolutely right that if that is all you're trying to do, you should use the System Exec VI. 


As another note, NI is not in the business of promoting solutions that we don't think offer the best chance of long-term success for our customers. We've seen many customers experience great success using Python and LabVIEW for larger systems through their use of the Python Integration Toolkit. While the tool might not be for you, the intention of the article was to raise awareness that the toolkit exists and ignite conversation over Python integration options with LabVIEW - which I thank you again for contributing to. 


I, personally, would be very interested in seeing your Dynamic Simulator example. As X. mentioned, that would probably be more appropriately placed in a LabVIEW forum thread that's more geared towards technical discussion and implementation. It'd be great if you could provide a link to that forum after it's created for anyone who browses here to find later!


Again, thanks for all the valuable feedback! I appreciate it!



Member skim173

Hi all,


First off, I am very glad to see this article since I didn't know how may LabVIEW engineers and Pythonists want to build integrated systems with both tools like myself.


To be honest, I would say that this article seems like an AD for that toolkit but I don't think it is bad or wrong since someone might need that toolkit somewhat reason. 


Anyways, I wrote some code to get data so the flow is like below:

DAQ => LabVIEW => UDP => Python (Jupyter notebook)

This combination works pretty well for my small project so that I will use this setting in the future actively.


My point is, I will just use both tools for my needs and I will use the toolkit as well if I need. LabVIEW gives me a lot of convenience for real time applications and Python gives me a lot of convenience for complex/flexible calculations. 


If there is a forum for that kind of combination (lv+py) I would like to subscribe it to expand my knowledge.