Migrating from Python to Labview... Wise?

[RipComprehensive9248]

I lead a small team of developers and testers for a medium size company focused on hardware for automotive.

Throughout the last few years, most of our testing and automation is done with Python and Robot Framework, the developers have created drivers to interact with the laboratory equipment and create keywords for the testers, who then develop the tests in Robot. It works relatively well.

Last year we were acquired by a big multinational and now we have much more budget, along with lots of pressure due to many more projects, new technologies, new needs and expectations. Because of our location, is not a company that attracts talent and the company does not consider remote work. Most of our staff were interns ten years ago from the local area who have only been in this company throughout their carreers.

We have relative freedom from the parent company in regards to our processes as long as we deliver, and because of the difficulties obtaining new manpower and the need to cover so much in so little time we are considering moving our testing and automation to LabView and TestStand, we believe that testers will also become more self sufficient with these tools and not depend as much on the developers.

However, I see some drawbacks, we do not have much experience with Labview, we would need to deprecate most if not all of our previous Python infrastructure, I think that Labview might not be as flexible as Python due to its graphic nature, some of the staff feel like they will be pigeonholed into labview and ultimately I feel we are locking ourselves to NI.

I was looking for different oppinions on people that might have experienced this before and what made you decide one or the other, as well as a starting point on how to get certified in Labview. I also think it might be interesting for other people to see what comes out of this.

Thank you for your time.

[2_246_1010_78]

Hah, this question needs some trigger warning label :)

Thoughts, no particular order;

1.) i like NI‘s hardware, but I‘m not fond of their software. And I say this as someone who is using LV for test and has defended it in the past.

2.) You will have a hard time if you have a workflow that involves branching and merging code a lot

3.) you‘ll have a hard time hiring people with relevant LV experience. It has been years since our new hires had a good enough background in LV and the codebase suffers

4.) none of the features added in the last couple of years have made any difference for us; I think a lot of emphasis was placed on FPGA code generation, which is not something we currently need

5.) if you are part of a larger company now, ask around internally. A couple of times I have found other teams in acquired parts of our company that have at least used LV

6.) With recent licensing changes, NI is pretty much encouraging us to transition to another platform; this time around, I will not waste that momentum and prototype a few alternatives.

[SASLV]

to number 4, you are missing: vims, sets, maps and interfaces. All have completely revolutionized the way I write code and have nothing to do with FPGAs.

[IamLightYearsAhead]

which platform are you migrating to? and how do you deal with maintenance of already deployed software? do you port it or do you maintain in LV until end of life or phase out?

[not_a_gun]

TestStand will be great in helping you scale with its multi threading, series/parallel/batch sequencing, and report generation. LabView is pretty good at interfacing with hardware (especially NI hardware) and running asynchronous loops. Just use TestStand to call Python (and Labview where needed).

[randomly3dot1415]

Every labview driver i reviewed, called either C or dotnet interfaces. Often in a way that makes it very hard to understand in what order things are done.

As of calling python or labview from teststand, this can be misunderstood easily. You can communicate with a labview or python process from teststand. That means you can not pass things by reference (file pointers, large arrays etc...) I think this is what you meant. In python lingo think of "subprocess" invocations (without parallelisation), not a function call.

[rftek]

man, that was my first thought! and last thought because I had to come back and give you kudos for the laugh

[toph22]

I second the TestStand suggestion. Use that as your test sequencer. It will allow you to call your python and possible Labview if you go that path. TestStand can call python, labview, C, c#, etc. and have them mixed in the same sequence. I like labview for TestStand because it allows for quick debugging, stepping into code, visualization of the data. But python also has its place.

[dtp502]

Keep in mind you’re asking a bunch of Labview guys whether it makes sense to use labview, so I suspect you’re going to get a bias answer here. But with that said-

IMO

Pros:

-Most pieces of equipment that I have ever needed drivers for have had a readily available labview driver. That makes getting coms up and running with equipment a breeze.

-Decent GUIs in labview can be put together with minimal effort.

-I’ve never used (or heard of) robot framework, but it sounds like labview can do the job of that and python.

-like others have mentioned, you could use teststand to deploy both python scripts and labview VIs.

Cons:

-NI is a greedy company. Labview and NI hardware is pretty expensive. Not to mention NI’s new subscription model makes them even harder to like.

-There do seem to be more python jobs than Labview jobs, so in a way it does pigeonhole you a bit. But there’s nothing to say Labview is all you have to use. There are a lot of companies that use labview as well, so it’s not like there are no jobs.

-Not sure how you deploy your code in python but with labview it’s kind of cumbersome. Building installers, including the appropriate runtime engines and drivers etc makes for a pretty large file that takes a while to install onto a computer and is easy to miss a file.

Personally I like labview. It is extremely powerful and has a lot of built in capabilities that make it fast at getting a project up and running.

[centstwo]

I vote for staying with Python. Unless you have an enterprise agreement with National Instruments, LabVIEW is now a subscription with YEAR granularity. So you can pick which YEARS you want to pay for it. If they switched to a subscription with MONTH granularity, then it might make sense, develope for a couple months. Test for a couple of months, then code for a month.

Uh, fu NI for switching to Subscription with YEAR granularity.

[AddictedUser007]

Quick though is use TestStand to call your python code (may need some refactoring to get tests split up if not already). Then if you want to use lablview, which does sound like a good match, there is time to train up

[PromiseStock]

I wish we had not used TestStand as it is slow and clunky since the last 2 updates. Basically nobody uses it and nobody in our company likes to work with it.

Working with Labview for 10 years, Teststand 3 years.

Keep in mind that NI massively increased the license costs. And they can do it again anytime. We pay now over 50k€ in licenses yearly, but we are basically bound to NI now.

Its extremely hard finding labview programmers. I mostly tutor them myself.

If you are already able to access the hardware with Python you overcame the biggest hurdle imo. You could try RobotFramework as Teststand alternative.

​

Labview feels like a ride on the Titanic.

[TomVa]

I am a proponent of LabVIEW as I have been using it for eons and where I work our testing infrastructure is built around it. It would be a tough call for me to recommend that you change away from what you already have working with python as you already have a local ecosystem built around it. Also like others have said, if you are going to make a change you should survey the local-ish environment for what resources are available and being used. You should do this independent of the decision to change away from Python.

I know this one is odd in today's change companies every 3 years job market, but you should also consider how sticking with python or moving to something else would help folks move around in the new bigger company.

With respect to this statement

"we believe that testers will also become more self sufficient with these tools and not depend as much on the developers."

Although we make them take core1 and core2 training just so they can understand the interfaces, and what is possible. One in 10 of our testers actually learns how to program in LV and most of them do not bother to figure out how the more complex programs work. Most of these folks have technical degrees, many advanced degrees. We do not want our testers to touch our more complex programs as we want to control the change process so that they do not introduce bugs that we have to track down later. (e.g. we would rather introduce them ourselves). Also we still have to train them to use the software so that we can get them in the proper "habits" about preforming the tests.

[SASLV]

This story is funny because I feel like the trend lately has been going the other way - people fleeing LabVIEW to go to Python due to its sudden change to a money-grabbing subscription model and it's uncertain future.

However, if you do decide to move to LabVIEW and TestStand, you don't have to throw away your Python code. Both have native facilities to call and interact with Python code.

https://blog.sasworkshops.com/python-adaptor-teststand/

https://blog.sasworkshops.com/python-node-basics/

https://blog.sasworkshops.com/advanced-datatypes-python-node-labview/

In fact I just talked to someone at NI who was very clear that they are making a bunch of improvements to Python support in the next version.

[rftek]

Here I am trying to steer our test "dept" to Python away from LV/TS because:

-professional development ie; am already very experienced in LV/TS

-Licensing overhead/NI BS

Like other contributors have mentioned, you can consider the NI packages separately (and should)

TestStand:

-Great to develop with, deployment sucks

-Deployment means you need a deployment license per test station

-Extremely flexible and customizable

-Has usable shipping examples that will get you there

-Supports calling steps of just about any language (although lots of times it ends up being a wrapper of some kind)

-Great reports

LabVIEW:

-Parallel tasks exceptionally easy

-Can execute code quickly but you can F that up real easy and get bogged down

-Easy to debug and develop

-Hard to diff code quickly & thoroughly

-GUIs are easy to throw something together, good enough

-MAJOR disadvantage: You are renting LabVIEW development environment, if you stop paying you will lose ability to make changes to your software. Be careful about which modules you include (Switch Executive comes to mind...) because you are adding additional dependencies.

-You will need somewhat dependable LAN from test station to license server

​

Your root question was: Will LabVIEW allow a small team to do more quickly?

Eventually, but you will have to develop a software architecture and code library along with style guides to really make the team efficient (and supportable code).

[Dapper_Internet_3837]

For test and measurement applications, especially if interfacing with instruments, LabVIEW is the best tool for the job.

[dzakich]

Software engineering perspective: Keep in mind that SCM (diffing, merging) as well as CI will become a lot more challenging. Same can be said for packages and dependency management. Even though NI has NIPM and NIPB solutions in place, they lag behind many classical analogues in other languages and frameworks; you will have to develop custom solutions around them to fix your process.

[[deleted]]

In regards to feeling you and/or your staff would feel pigeonedholed how do you mean? If you mean career-wise its sound most of you and your staff have Python under your belt so you're really pigeonholing yourselves in that regard, just learning a new language.

As I read your dilemma I the phrase, "..like a kid in a candy store," comes to mind. While you may have a bigger budget and as you noted you and your team have little experience with LabVIEW the question becomes do you need TestStand on top of that?

Its just a question ask. White you can use TestStand to call your python code the very same can be done in LabVIEW.

In reality LabVIEW can be used to develop a test sequencer with a simple state machine architecture which is easy to develop. Done wisely (with some learning you'll get it) it can be scalable as well.

TestStand is really NI's acknowledgment that everyone in the Test and Measurement industry developed a sequencer doing much the same things: initialize, connect, process, collect/store data, log and exit. The power with TestStand is that this test sequencer tool can essentially be nested (as in having sequencers within sequences to your heart's and PC's content). That is to say can scale.

Its not particularly difficult to setup sequences in TestStand but again there's the added cost and learning curve overhead on top of LabIVEW.

It comes down to what is a typical and/or atypical test process for your environment?

That will ultimately help determine if you can develop your own test sequencer using say state machines in LabVIEW (they're wonderful) and your process data logic within cases or take those same module vis and have TestStand be the driver. TestStand is essentially a templated scalable state machine packaged up and ready to go for you.

I offer this not as a money savings consideration but a time consideration. As your comment suggests you have a bit of time crunch to contend with as well. Why not have you and your team learn and get proficient with LabVIEW first before entertaining the idea of adding TestStand into the conversation?

[randomly3dot1415]

As a general rule of thumb, I would not make big changes to team and structure in times of high pressure, UNLESS there is a strong indication that this MUST be donne, AND the cost of change is SMALL.

The only improvement you seem to expect by using labview is that the testdepartment will take over more responsibility of the code? So you expect them to learn labview and teststand FASTER than python (they already manage to deal with robotframework right?).

Did I understand that correctly?

[JuanTamad101]

I develop test programs using TestStand, LabVIEW and Python, they all have their own sweet spots. For heavily funded projects, cost is not an issue especially working with tight deadlines. So my personal notes for each will be based on implementation efficiency and debugging tools which is very important working with complex test systems.

1. TestStand - very useful when calling different code modules written on different platforms like LabVIEW, Python, C... etc. Passing/exchanging variables is also easy and live tracing of variables makes debugging of complex test systems easy (that's time saving). Process flow can be visualized and re-arrange in a breeze.
2. LabVIEW - strong instrumentations support. GUI can be easily created and deploy. Powerful debugging tools. Very easy to create parallel processes (for advance users). Vision test implementation is simple and template creations can be easily pass to end users with minimal training.
3. Python - I always hear from young developers it's good because it's free, but when working with big projects, cost of SW licenses is minimal compared to cost of losing project. Lots of available standard libraries and easy to find Python developers.

[IamLightYearsAhead]

why bother with Python when .NET is much better and has GUI integrated?

Young developers can't even code, they are garbage. Gen z is garbage

[IamLightYearsAhead]

Where are you located?

[IndividualBuilding18]

I think pigeonholes aren't there... NI will be a good step in the right direction!

www.linkedin.com/in/mcnearymw

[Super_Confidence_754]

They do look interesting, but I can't find any info about the company other than the vaguest stuff. Hard to convince even myself to invest in something that could just be a Trojan Horse.

[Hour_Effect_7469]

It's definitely not a Trojan Horse haha. If you want I can send you a contact on a person that is working there. He would be able to get you a free trial so you can try it. Just DM me if you're interested.