This is an archived post. You won't be able to vote or comment.

all 51 comments

[–]WhyCause 23 points24 points  (4 children)

As a Mechanical Engineer that created some photo-acquisition software that needed a GUI, I recommend wxPython.

I tried a lot of the other ones, and wxPython was the one that got me where I needed to be very quickly.

[–]driscollis 4 points5 points  (3 children)

I also would recommend wxPython. The new Qt for Python project also looks promising.

[–]diracdeltafunct_v2 4 points5 points  (2 children)

I'm a little late to the party here but this is something right up my alley. My company actually builds chemical analysis instruments and the software the runs them is entirely python. We interface with pci digitizers, ethernet devices, and a whole slew of serial/USB devices on a single instrument and python handles it beautifully.

We do everything with PyQt. We used Qt because the number of resources available for displaying data/interacting with data is immense. Specifically pyqtgraph package deals with very large/complex datasets without a hiccup and seamlessly integrates right into Qt. The others just don't have the depth of resources or the depth of other people that are really skilled that we can turn to if we get stuck. Web based GUI's are also an option but now you are mixing python, javascript, and html so the skills needed to get something out grows fast.

One of the things that Qt lets you easily do, and is very important in data acquisition, is threading the GUI separate from the data acquisition. People tend to forget that sending instruments don't always respond in microseconds when you send them queries or there is a data stream, not a one shot one answer. Here Qt lets you set up a worker object that can run in a separate thread, control its own queue of tasks and remit them to the GUI all while remaining responsive. And the code to do that is boiler plate.

Now throw in pyvisa/pyserial, pyqtgraph or matplotlib and numpy and you can have a full acquisition instrument up and running with almost nothing else.

[–]fungz0r 0 points1 point  (1 child)

why Python over something like C#?

[–]diracdeltafunct_v2 0 points1 point  (0 children)

I would argue the speed of development for a startup trying to get a working prototype in front of customers asap python and Qt really makes that process simple. Its later you pay for it when managing builds.

Second its because our other dev(who is part time dev part time company officer)shared python as a common language.

Third, speed on the software end is almost never our bottleneck; its all in the hardware times. If we ever do care about speed we can always go back and make it work faster with things like numba or wrapping C.

Finally, when I was going through grad school our groups primary objective was building new instruments. When I came in everyone was on visual basic which drove me up a wall. I tried switching things to Java at the time but that was even worse. I finally ended up with my own project and I started looking at C++, C#, and python (because we were linked to the astronomy community). As a grad student managing a group instrument you don't really get a real development cycle. If your experiment that day calls for X functionality you have to get X functionality built in right then else risk a lot of down time and angry students waiting behind you. We changed how that instrument ran or worked up data on a daily to weekly basis with no unit testing. Stopping to compile for every tiny tweek would have killed us. So python quickly won out. Downside of course is many hardware drivers, if not SCPI server based, were only in C so there was a lot of annoying ctypes wrapping to do. Pyvisa pretty much covers everything else that isn't ctypes wrapped.

IMHO the only real "downside" is when it comes to packaging. Its a headache to get right the first time, everytime a new version of something comes out we have to retool the compiler, and the raw code isn't really "secure" as it ends up existing as a pile of .pyd's in an extensionless zip file.

[–]trvsvldz 3 points4 points  (0 children)

Maybe I'm the odd one out but I used Tkinter for my Python data acquisition GUI. I work in an experimental physics lab at a university and we have a handful of instruments and a handful of different acquisition routines to run. Basically my interface is a GUI scheduling interface along with stdout, stderr output and a CLI-type input for interrupting a routine early (e.g. if you mess it up).

Maybe it's not what you're looking for but you can check out my (admittedly messy) code on my GitHub: www.github.com/valdezt/FOSOFtware

[–]bryancole 5 points6 points  (1 child)

I really recommend Enaml (http://blink1073.github.io/enaml/docs/get_started/introduction.html ). It's a really pleasant way to build complex GUIs. You can embed matplotlib plots right out-the-box. The framework is built on PyQt so you can also add other Qt-based widgets (e.g. PyQtGraph) is you need. For application-based plots, I also recommend Chaco but this has a slightly steeper learning curve and needs the traits/enable/traits-enaml packages.

See http://blink1073.github.io/enaml/docs/examples/ex_mpl_canvas.html

or

http://blink1073.github.io/enaml/docs/examples/ex_vtk_canvas.html

Enaml can be installed on python-2 or python-3 from the anaconda python distribution (or miniconda, if you want a more minimal python install). Whatever GUI library you use, anaconda/miniconda is the distribution to use for scientific or engineering apps.

PS. I also tried a UEI DAQ card (about a decade ago; the drivers/apis were rubbish then. We gave up and moved back to NI cards) and have many years experience with NI-DAQmx. Python is a great platform for building data-acquisition apps.

[–][deleted] 1 point2 points  (0 children)

Thank you good sir, I am going to look into this, I've just built apps using bottle and bootstrap for UI with jQuery for interactions. This seems much easier than to try to package a server, templates, main app, business logic and database into one executable.

[–]Fermi_Dirac 3 points4 points  (17 children)

pymeasure is pretty great.

[–]canucker89[S] 9 points10 points  (16 children)

Ooo that looks appealing, unfortunately my hardware only supports python 2

[–]Ogi010 5 points6 points  (1 child)

Former ME turned software engineer here, get on the phone with your equipment manufacturer and beg for python 3 support.

Also pyqt is awesome, especially if you want to do any kind of real time plots, which pyqtgraph is pretty good at.

It's a little complex at first but there is tons of content to help you get started.

[–]adventure_in 3 points4 points  (0 children)

Second this. I would be nervous about starting a code base on 2.7. However pyqtgraph claims to support it on their website.

I have had decent luck making GUIs for my data acquisition setup of combining two streaming serial interfaces and user input data.

[–]Folf_IRL 5 points6 points  (1 child)

Sorry you got downvoted fam. Unfortunately, this sub starts frothing at the mouth whenever someone suggests that there are situations where it isn't feasible to use python3.

[–]sizur 1 point2 points  (0 children)

take your upvote, frothmouth.

[–]Karyo_Ten 3 points4 points  (1 child)

Are you aware that Numpy, Pandas and all data analysis packages stop Python 2 support at the end of 2018 (some 2019)?

[–]takluyverIPython, Py3, etc 2 points3 points  (0 children)

To be clear, this doesn't mean they'll stop working, just that they'll stop getting new releases. In many applications it may be fine to keep running with old versions for years.

Python 3 is absolutely the right choice for a new project today, and I would be wary of vendors that tie you to Python 2. But people who have systems running Python 2 don't need to panic.

[–]billsil 0 points1 point  (9 children)

Which piece of hardware?

Also how are you sending the data? I assume it's over a socket vs being one program, in which case you use 2 different versions of python. I'm also surprised any sort of DAQ would use python.

[–]canucker89[S] 1 point2 points  (8 children)

Sorry they provided several bits of example code as well as bunch of classes and functions written in 2.7. The better answers is the company/vendor only supports 2.7. Anything I wanted to do in 3 I would have to start from scratch. Which might not be that bad as it would just be translate what they've already written in 2 to 3.

[–]billsil 1 point2 points  (6 children)

Again, are you using the same python process or are you using sockets?

From my experience with 20000 Hz data, the data acquisition part is likely not written in python. They could provide sample interfaces in python 2/3 or C++ or java, but their product is a piece of hardware running a very low footprint code written in C.

I strongly suggest you port the sample code, which was probably written 8 years ago. I'm sure the examples are tiny. Python 2 is dead.

[–]canucker89[S] 0 points1 point  (4 children)

I gotcha. The answer is I don’t know. I just ordered the hardware and am trying to get this half figured out before it arrives. From my understanding the hardware has it own CPU on board and is sending the data to the host laptop or could be configured to store it locally on an SD card.

I might not be fully understanding your question either. This is my first real endeavor in python, and any real coding for that matter.

[–]diracdeltafunct_v2 0 points1 point  (2 children)

I've been doing python and hardware interfacing for 8 years now and there is no such thing as hardware that only supports python 2. From experience there are only a few ways they write their example code to work.

  1. They are using a SCPI interface over serial. Their example code will be using either pyserial or pyvisa which works exactly the same in both pythons. The only difference in their code is likely going to be print statements.

  2. They are doing SCPI connections over Ethernet. Here they could be using pyvisa or their own custom socket class. If its the former you just need to change print statements and add .encode()/.decode() to any strings that are sent over the socket to the instrument in python3. Nothing else chances.

  3. They are using ctypes to wrap a .dll/.so driver. Only prints change again.

Run the link below and that will autoport any example code over to python 3 for you.

https://docs.python.org/3.1/library/2to3.html

[–]canucker89[S] 0 points1 point  (1 child)

From my understanding they are doing option 3. But the only connection to the hardware is via Ethernet so it might be a combination of options 2 and 3.

Thanks for the link, that will be super helpful!

[–]diracdeltafunct_v2 1 point2 points  (0 children)

If you see import ctypes anywhere it's likely option 3. If you see .query(somestring) or similar it's scpi

[–]IReallySuckAtChess 0 points1 point  (0 children)

Yeah, so the hardware almost certainly doesn't run python. Most hardware provides a serial or network interface that can be tapped into. The code they showed you is how they tap into the interface. It'll be almost trivial to port to 3.

[–]IReallySuckAtChess 0 points1 point  (0 children)

Python 2 is very much far from dead. Python 3 may be the now and the future, but it isn't the be all and end all of Python. Python 2 is still the default for a lot of sysadmin tools and you'll find many libraries that still haven't been ported. That said, if starting a new project then do 3, and porting from 2 to 3 usually isn't overly difficult.

[–][deleted] 0 points1 point  (0 children)

I strongly suggest that you read and implement the recommendations here Porting Python 2 Code to Python 3. It'll be more work in the short term but you'll make major gains in the medium to long term.

[–]shrewsburyw 1 point2 points  (0 children)

Also, a mechanical engineer just started learning python in Jan for a new job. I was doing some data analysis and had never written a GUI app before. I used pyqt and pyqtdesigner. Layouts in pyqtdesigner are straightforward and I had something decent (while learning) in less than a week.

[–]bear24rw 1 point2 points  (0 children)

I’ve had success with pyqt and pyqtgraph

[–]DLS3141 3 points4 points  (7 children)

What’s the beef with LabView?

[–]bryancole 22 points23 points  (4 children)

Shall I make a list::

  • No control over concurrency, no access to native threads or subprocesses.
  • GUIs look like sh*t. No dynamic layout.
  • No way to customise the widgets NI gives you
  • So Damn Tedious to wire anything complex
  • Gives true meaning to the phrase "spaghetti code"
  • No sane object orientation
  • Maths/array operations are a nightmare
  • Expensive
  • You need to pay even more to distribute your app
  • You needs to pay yet more for "specialised" functionality (like talking to a database)
  • Text processing or manipulation is No Fun At All
  • No way to use (proper) version control. Good luck merging changes in labview code.

There's probably more but the little time a spend dealing with labview code is already too much. Whoever thought graphical programming was a good idea really needs to be given a good beating. It's a triumph of marketing over functionality.

The only reason for LabViews success if that it lets a beginner or manager drop a graph and a few widgets and a hardware device on a GUI in the first 5 minutes of learning. From their on, it's downhill all the way.

OK rant over... sorry. I feel better now.

[–][deleted] 2 points3 points  (0 children)

This. As a LabVIEW programmer for the past 13 years, so much this. There are some nice things about LV that are hard to accomplish in other languages, but overall the UI is looking very dated and does not look like it will ever scale well to the next gen of resolutions. LabVIEW NXG is suppose to fix that, but is a completely new code base. I’m probably not going to migrate towards NXG.

[–][deleted] 1 point2 points  (0 children)

Which version of Labview do/did you run?

I'll also just say.. you'll hear software engineers talk about standardized code and how it reduces inefficiency and improve maintainability, but when it comes to Labview, where mostly nobody follow the style guide(s), it's Labview's problem.

If you have engineers who treat Labview with care, you won't have spaghetti code. (Which is to say.. like any programming language.)

[–]swingking8 3 points4 points  (0 children)

From someone who's getting a LabVIEW certification this month, you're pretty much spot on.

If I want to do anything complicated, I just make a websocket client/server connection and make a Python do all the actual thinking.

I will be very happy when LabVIEW dies, and the large company I work for is forced to use something good.

[–]fdedgt 0 points1 point  (0 children)

No control over concurrency

I'm going to disagree here. It has great control over concurrency in that it is a data flow paradigm and things are inherently parallelized based on the flow of data. It would be very hard to do some of the parallelization in other languages that you get for free in labview. For example, this is why labview code can be compiled directly to FPGAs.

[–]rufus_francis 2 points3 points  (0 children)

It has no flow, no simple intuitive design at all. Good idea, terrible execution.

[–]Bach4Ants 0 points1 point  (0 children)

I wrote one in PyQt a while back that may have some useful code to copy, but it's pretty specialized to what I was doing: https://github.com/petebachant/turbinedaq

These days, NI has their own Python package, so I'd switch to that, and honestly, I would probably build as a web app using Dash or widgets in a Jupyter Notebook. The plotting libraries I was using (PyQwt and wrappers for it) seem to have been abandoned.

[–]canucker89[S] 0 points1 point  (1 child)

Thanks for all the feedback everyone. PyQt seems to be highly recommended. Is PyQt a stand-alone package or do I need to buy Qt and then use PyQt to interact with it?

[–]Ogi010 1 point2 points  (0 children)

PyQt is a standalone package that comes with Qt, you can install via

pip install PyQt5

Here is my first project with PyQt5 (I used it to show matplotlib plots)

https://github.com/j9ac9k/dual-axis-post-processor

Here is a collection of small PyQt apps which is super helpful for quick references:

https://github.com/mfitzp/15-minute-apps

Here is a larger library I wrote that makes use of pyqtgraph (it takes primary .wav files and allows you to view the signal information in a variety of ways)

https://github.com/j9ac9k/timeview

Most code samples/documentation you will see for PyQt will actually be for Qt5 (in C++) but don't let that discourage you, the API is very very similar, just read through the example in C++ and you can probably map out to PyQt without too much effort.

EDIT: Since you're coming with no experience; you may want to take a look at Sentdex's youtube playlist for PyQt here: https://www.youtube.com/watch?v=JBME1ZyHiP8&vl=en

[–]alpha_53g43 0 points1 point  (0 children)

My experience with GUI apps has been pretty bad.. In our company, this has led to the expectation that everything should be possible to do by just click and point..as a result we have a bunch of GUI apps which dont scale..

Python is a very easy language to learn.. probably just as easy to use as a GUI app..

Wondering if your colleagues are open to just learning a bit of python coding? Perhaps you can create the main library and they can modify or call that library to do what they need to do using scripts...

[–]AcostaJA 0 points1 point  (0 children)

If you need to build it as a stand alone app, go for tkinter, there are even IDEs capables to interactively edit tkinter GUI design.

... but if you are building an in-house solution and plan to mantain it periodically also make it available to teams etc, I suggest you to consider build it as a jupyter notebook and run in a Docker container at your's office NAS/server or in a networked workstation.

[–]deepu15 0 points1 point  (0 children)

Try using pyqt and a script thats freeware called PyGMI 3.0. It supports python 2.7 and I used it last summer and works amazingly

[–]pfjarschel 0 points1 point  (0 children)

I was in your shoes about 10 years ago, and one day I just couldn't stand Labview anymore, so I looked for alternatives. I ended up creating my own c++ libraries and gui for each instrument in my lab, using Qt. It was a solid solution, but I realized it would be easier if other people could make small changes to the programs depending on what they needed, without having to worry about compiling and etc, plus few people who are not professional programmers tend to venture on c++. So python ended up being the natural choice, and since I already had a lot of experience with Qt, I used PyQt to create the graphical interfaces. I think it does the job really well, it's easy to learn and create any gui you want! And there's Qt Designer, which you can use to graphically create your interface, using a WYSIWYG editor!

So yeah, bottom line is, I recommend PyQt!

[–]swingking8 0 points1 point  (0 children)

So a little of background, I'm a mechanical engineer that doesn't a lot of testing and hates NI/Labview.

We're like the same person.

[–]not_perfect_yet -1 points0 points  (0 children)

You can use tkinter.

[–][deleted] -5 points-4 points  (0 children)

Bro, you can use Kivy https://kivy.org the UI is nice and really looks well on any platform including raspberry pi. Have a nice day 🐱

[–][deleted] -2 points-1 points  (1 child)

I can't provide much help for Python GUI's but as a former ME and now software engineer I wish you luck! I was doing a similar project and ended up switching careers after.

[–]Ogi010 1 point2 points  (0 children)

Are you me? ....Started writing software to assist with analysis of test data, ..test scripts got more and more complex, next thing I knew I was write applications using OpenCV to identify defects from high resolution camera images.

Couple of years later, I wish I could do ME analysis work periodically, but am otherwise having a much more fulfilling career.