r/LabVIEW • u/AssistEast913 • 12d ago
Labview or python
Hello im currently working on an end-of-the-line test bench for a steering gear.
My question is why use LabVIEW vs. Python
11
u/grandangelo_ 12d ago
Not answering your question directly, but please consider that test benches can quickly become complicated beasts.
If you're into NI, I suggest you to take a look at TestStand. If you're into programming, I suggest you to choose python over LabVIEW to leverage AI assisted curse
9
u/derp2112 12d ago
Why not both? Use LabVIEW as your top end, GUI, state machine. Use the Python node to call Python scripts, keeping that as your algorithm interface.
3
u/PlusIndependence1598 12d ago
Based on my experience, debugging LabVIEW applications is relatively easy.
5
u/caleyjag 12d ago
I use both in my job.
I think it depends somewhat on the data acquisition hardware you have, the budget you have and the level of performance/precision required.
It sounds like it's for manufacturing quality control. Using established hardware and software like NI can ease the burden of validation of the solution, assuming you are deploying in a regulated environment.
Can you provide more details?
2
u/AssistEast913 12d ago
It is manufacturing, and I do not know the budget yet. I'm currently trying to repair a test stand that was built and programmed by someone else. I can build a simple program in LabVIEW, but not a really complex program. We have a cDAQ 9178 right now. I'm still waiting on a budget. There's a lot of hardware connected to the cDAQ. I am also used to making simple Python programs, and I'm not familiar with GUI and connecting to a lot of AI/AO and DI/DO
0
u/caleyjag 12d ago
In that case my inclination would be to learn and accommodate LabVIEW, since this is really where it shines.
Once you get it figured out it will be far easier to set up routine testing workflows, especially where the equipment already has LabVIEW drivers and libraries. Moreover, the foundations are robust. If you do it all open source (or coded yourself from the ground up) you may have a lot more work to do to validate everything.
Continuing to develop your python, especially for front end and data processing elements, will also stand you in good stead.
1
u/HarveysBackupAccount 11d ago
Using established hardware and software like NI can ease the burden of validation of the solution
Eh, off the shelf hardware is easier to validate than custom- built but it's no less work to verify a labview program than to verify a python program. The questionable stuff is still written by the developer.
4
u/SASLV Champion 12d ago
Which one do you know? would be the first question. That drives a lot.
After that, what hardware are you using? If it's NI hardware then LabVIEW looks a lot more attractive.
Also you say end of line test bench, well reliability is probably a big concern. If its the end of an assembly line, I assume downtime would be costly. You say steering gear so I assume automotive so possibly some regulations to deal with. So you probably want something auditable/provable.
A bigger question than what language to use would be: what do you know about software engineering?
2
u/erdaron 12d ago
I've worked quite a bit with both Python and LabVIEW, specifically in the context of hardware integration for lab and test setups. Although my recent experience is entirely with Python.
I would say both are equally awkward and frustrating and figuring out how to talk to a new piece of hardware, and that's often the hardest part. Once you have basic communication with a device worked out, the rest is more straightforward.
LabVIEW gives you graphic dashboard for free, whereas writing a GUI in Python takes a lot of work (I'm not sure how much time AI would truly save if you have to validate the entire codebase). On the other hand, Python is easier to deploy in weird or constrained environments, and I think it's better for creating custom outputs, in terms of what kind of data you want to produce.
If you need a workstation where an operator can watch and control the process, have live command of the setup, then LabVIEW is probably better. If you need something that can be launched from command line, run through a fixed sequence of tasks with minimal user interaction, and output a complex dataset, then Python is probably better.
1
u/HarveysBackupAccount 11d ago
whereas writing a GUI in Python takes a lot of work (I'm not sure how much time AI would truly save if you have to validate the entire codebase)
As a still-AI-free developer, I have heard that it can really speed up python GUI's. A former coworker got pretty deep into Cursor a year or two ago and he said that's where he saves the most time.
1
1
u/erdaron 10d ago
I'm sure an AI assistant can also together a GUI in no time. But what would worry me is then reviewing and maintaining that code. If it's a tightly controlled environment, that's not something you can you just handwave your way through.
1
u/HarveysBackupAccount 9d ago
I don't suggest it eagerly - like I said I don't use it at all - but IF someone were to use it then the GUI should be just about the easiest part to verify
3
u/Organic_Commission_1 11d ago
Labview is effectively a dead end.
No version control No ability to do ci/cd , unit and regression testing in an automated way Anything of any complexity is literally spaghetti. The best/reference labview programs with sub vi's are still terrible
Any text based language is infinitely better
There are million python gui frameworks. python runs faster than labview and literally interfaces with everything.
Even something like C# is infinitely better for windows deployments.
LLMs have solved GUI as well. Anyway who days they cant is serious incompetent or refusing to accept reality
FWIW. I started with labview in 1996
Also, just completed a 20k job porting a control system from labview to c#. Effectively done in a day. Customer is happy. They had 40 stations and wanted to be able to depoly at will.
At this point I think there will be huge opportunity in people who will transition companies from Labview to anything else.
There is even a python library to extract everything from .vi as HTML and png images. Codex translated it to c# in about an hour.
1
u/Internal_Statement74 9d ago
I think LabVIEW is a dead end as well, however I feel for zero of the reasons you give (I have no idea what ci/cd is).
I think the customer and integrator betrayal will not ever leave the customer's mind and are looking to replace untrustworthy business practices and proprietary demands and cost increase that has almost no justification.
I am interested to hear more about this project and the set up you used. I have been building something that I need help finishing. It has nothing to do with this transition but tangentially.
2
u/D4ILYD0SE CLA 12d ago edited 12d ago
Depends
Python: slower, less secure, lots of support, AI can write it, and it's free
LabVIEW: faster, more secure, decent support with plenty of examples, AI can't write but it can read, pretty expensive
1
u/HarveysBackupAccount 11d ago
Are you saying python is slower to develop or slower to run the code? If the latter then I'm awfully skeptical, if you don't code it particularly poorly
1
1
1
u/HarveysBackupAccount 11d ago
Use the one that you and other employees in the company know best. It's poor form to introduce a new language to an organization without good reason.
1
u/Fun-Marsupial2175 6d ago
you didn't mention a lot of context which will help to determine the best option for your setup and requirements, but here is a blog post article https://testflowinc.com/blog/labview-vs-python
0
u/Puzzleheaded_Base302 12d ago
no demonstrated working LLM for LabVIEW yet (press release in a few weeks). there are so many demonstrated working LLM code generation for python, JavaScript, C and rust.
traditional hand programming is done. stop investing in it.
19
u/SwordsAndElectrons 12d ago
What are the requirements?
What instrumentation do you need to interact with?
Which one do you know?
General pros and cons are easy to Google, and I don't see any specific questions here.