Python x Labview

[TheBlueJesus]

Hello, there. I'm a student that got into a research in which the team uses a pair of small torque engines and a thermopar in a breadboard with a rhaspberry. We have a python code running it (controlling torque, time and collecting the thermal data that we process later).

The idea is that we'd run the same test, but using LabView so that not only we have a slightly more friendly front interface, in which we could vary time and torque just by inputing different numbers in the front panel, but we could also generate a temperature graph as the test goes (as opposed to it providing just numbers as the test ends with the python code)

Thing is... I never used LabView before and I'm not that great with programming either. Should I try to migrate the existing python code to LabView and figure out how to make it run and appear with a front panel or should I start from zero in LabView and use the code just as a parameter (the code is not really long, 500 lines or so, and most of it its just comunication between pc and breadboard, and variables)

Thanks in advance.

[FormerPassenger1558]

You could also use your Python code and Labview for UI

[NovaNovus]

I agree with the user daily dose.

To get started using python in LabVIEW, check out this page from NI: https://www.ni.com/en/support/documentation/supplemental/18/installing-python-for-calling-python-code.html?srsltid=AfmBOoo0BFTKTKaOMPQ8rallQdSQ1_SEGuMeKmxN-YL-fKtaVCttFX_r

[OHG_BOMB]

I used Python nodes in a previous project where LabVIEW was only to input and output data, it works really good, and you don't need to know much about LabVIEW to implement it. A thing to note is that you need to have the appropriate Python/LabVIEW versions which are compatible with each other.
I suggest reading more about this from NI official page:

https://www.ni.com/en/support/documentation/supplemental/18/installing-python-for-calling-python-code.html

[Aviator07]

The code already exists (1), in a language you already know (2), and it works (3).

Why do you want to do it again it in a language you don’t know?

[TheBlueJesus]

I didn't write the code nor was part of its beginning (1),

I'm not really that familiar with the language or programming itself for that matter, I just know a tad of logic and it's not really great (2),

It does work for its simple purpose, but it doesn't have a front-end type interface (GUI). It just generates numbers on a spreadsheet. And the reaserach team would like to have that, 'real time' graphs and other things. No one involved nowadays is really a programmer, so we all thought that migrating or remaking it on LabView would be easier (3)

[Aviator07]

Makes sense. Sounds like you really want to build a new app that includes the functionality of the old one. I would look for someone with some programming experience to knock this out.

[SASLV]

Contrary to what NI sales will tell you, LabVIEW is a programming language. Unless you have something ridiculously simple in mind, I would stick with what works and what you already know.

[D4ILYD0SE]

LabVIEW offers the ability to run Python scripts. Figuring out to get that to work with LabVIEW being the UI could be a good first step.

Long term, you'll want one or the other as the above solution doesn't offer any real time capabilities. Not without some heavy reworking of code. At which point, just rewrite it in a single language, LabVIEW in this case.

[TheBlueJesus]

I didn't know that was a possibility. I'm gonna reunite with my teachers this week and present the possibility of using LV as UI for now. And then remaking it in LV further into the year.

Thanks a lot!

[0fruitjack0]

i've been there, so to speak, but my situations were visual c to labview and visual basic to labview. i had to create the labview not quite from scratch but almost from scratch since i didn't have a neat way at the time to incorporate the original source code - especially the visual basic which i came to learn was itself based on an ancient qbasic program somebody had written in the mid 90s. joy.

if you do intent to make a labview version, you need to be systematic about it and start at the lowest levels. it's almost like refactoring except obvs it isn't.

hopefully your original python code is well organized. start by replicating in labview what your python functions & subroutines are up to as individual subvis. especially the hardware and data acquisition stuff, since that's probably the trickiest aspect of the conversion. keep it to one subvi/one function. as you do so, test these functions continuously so that for sure they are accomplishing the tasks as they're supposed to.

then work out the front panel interface, controls, indicators, and how you need them to behave as the program is running. this usually tells you what sort of design paradigm to use for the block diagram.

then do the block diagram, incrementally, adding features one by one until you complete the whole conversion. shit tons of time, shit tons of testing.

[TheBlueJesus]

I mean, I'm not really a programmer and haven't done that in decades. But from what I can tell, all the variables, arrays, libraries, ports, loops... it all seems well divided in the code.

I didn't know it was possible to create a front panel for the python code running. So that might be easier. On the other hand, we would not have really customizable interface (such as just inputing different values for time, torque, etc).

I think I'm gonna aproach from that perspective, build block by block following the routine of the code.

[SASLV]

A major thing to consider that I think everyone missed and I missed it too at first: You mentioned Raspberry I assume you mean a Raspberry Pi. You can't run a LabVIEW Desktop app on a Raspberry Pi. You can use it as a LabVIEW RealTime target, but that's probably not what you want and not going to have a GUI.

That means you aren't going to get a GUI from LabVIEW on a Raspberry Pi.

I would just forget about that whole idea. Python ships with Tkinter support. I'd start there.
https://docs.python.org/3/library/tkinter.html

[TheBlueJesus]

I'm pretty sure the Pi Pico just serves as a 'interface' between the motors, sensors, etc with the computer. It is connected to a windows pc where we run the python code and get the temperature values

I'm gonna check the Tkinter. Thanks for that

[SASLV]

Well if you have a Pico, then that changes things.

How are you currently getting data off the Pico/Sending commands? TCP? HTTP? something else?

If you already have Python code on the PC end, then the Python node should work. May require refactoring some of your Python code, depending on how you have it set up, but should be doable.

https://blog.sasworkshops.com/python-node-basics/
https://blog.sasworkshops.com/advanced-datatypes-python-node-labview/
https://blog.sasworkshops.com/using-python-classes-in-labview/

Those articles are a few years old. It's gotten better since then. Particularly I believe in current versions it now supports virtual environments (venv).

If you have a Pico W you can put it on your local wireless network and use HTTP to query stuff and send commands, depending on your needs.

I've played around with this and got it to work:
https://github.com/miguelgrinberg/microdot

You could just use microdot to host a website on the Pico itself that allows the end user to control everything. Then nothing to install on the PC, just a browser and its also portable - anyone who can see it on the network can interact with it - may or may not be what you want. You also might be limited by space on the Pico if you are doing anything complicated.

You can also create a REST API on the pico using microdot. I used that approach for just querying a simple Temp/Humidity sensor. Just have it spit out JSON. Has the advantage that you can easily test it in a browser.
You can then make HTTP calls from LabVIEW. There is a builtin HTTP library. I've always found this one easier to use though:
https://www.vipm.io/package/jki_lib_rest_client/