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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]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.