When I started my PhD in 2009 I was greeted with a really complex experiment control system written in LabView. Being the new guy I at first tried to figure it out and build my experiments on top of it, but I found it so frustrating that I eventually started rewriting it in Python. My colleagues & advisors did not approve of this and thought I would have to spend years getting the same amount of functionality they realized in Labview. So I did it secretly in the beginning while continuing to use the old system as well. After 6 months I had completely replaced the old system with a new one based on Python and C++ (for time-critical data analysis tasks that numpy was too slow for). I implemented a graphical IDE in Qt similar to Matlab where you could edit code snippets in multiple windows and execute them interactively. It was similar to Jupyter lab (which didn’t exist back then). I also wrote instrument front panels in Qt, class based abstractions for all instruments in our setup and a management layer that took care of initializing instruments and logging all relevant parameters. It was great fun and my first contact with Python, still amazed that the language allowed me to become productive in it so fast. The system is still in use and has spread to multiple labs by now, and my colleagues mostly acknowledged that Python is actually a good way to control measurement equipment and run experiments (though they still use LabView for simple measurements).

> LabView ... writing data into a database

You know, this is actually pretty easy to do if you know SQL and use LabView's FFI to call into a DLL for accessing the database. I did this once nearly a decade ago and was able to replace a system that took a (horrifyingly, horrifyingly incompetent — seriously, these people were so awful they needed state-level protection) team a year (?) to develop in a single afternoon. Oh, and mine didn't crash; theirs did. Anytime I think "this is the worst code I've ever seen" I stop, remember that code, and shake my head... that particular chunk of LabView just keeps winning (losing?). (The fact that they somehow had some sort of custom C extension with networked I-don't-think-I-ever-knew-but-it-sure-didn't-work in there probably makes it unassailable.)

That said... kill LabView with fire. Kill it dead. There's a reason that it's not listed on my resume and I'll deny any knowledge of it when people come asking.

(Personally, my biggest issue with LabView is its complete resistance to any form of version control. But there are so, so many other issues to choose from that I won't be sad if you pick a different one to hate on. Just don't use LabView and we're cool.)

My personal mission is to produce a version-control-friendly and open-source LabView/Simulink killer. Visual display for the managers, textual editing to save the poor engineers who have to program the thing from mouse-hand RSI. Do the whole thing in Python/C to make it both hip and fast.

Maybe you want to look at Modelica [1] for inspiration? It is an open modeling language standard with open source implementations. It should do what you want. maybe abit too declarative however (you can always use the algorithm block instead of the equation block though).

[1] https://www.modelica.org/

I was aware of OpenModelica, but hadn't looked at the project in any great depth. I think it's a lot more ambitious than my project, which is restricted (at present) to a single model of computation.

I remember as a kid that there was a thing called Visual C++ which sounds like what you're describing. It let me draw a GUI and connect functions to button actions or entry field contents.

Now I just use emacs and gcc because I write embedded code mostly but I'm trying to understand why your idea is different? Being open source?

Honestly .. I would love for this to happen.

I was recently involved in a LabView eviction. I was shocked to discover that one of the modules which looked superficially complicated was actually "short circuited" and most of the logic was not contributing to the final output. At a glance it looked like everything was wired up, but looking closely there was a single missing link that completely changed what the module did. That was enough to convince me that it's a toy and nothing serious should be attempted with it.

How is that different though from forgetting to pass in an argument into a variadic function, or having a spurious early return? To the untrained eye, both those scenarios would present the same.

Any compiler or linter would likely complain about unused variables or code in such a situation.

The labview "linter" is of course weirder but I think this is basically one.

https://zone.ni.com/reference/en-XX/help/371361R-01/lvvianal...

PS. Please don't take this as an endorsement of labview. It has its place in non-CS fields when there's high turnover so it's really bad if only the group's current programmer understands it. Talking academia here, I probably wouldn't use it in a more stable environment.

Not if a part of the variable is used

I just had this problem in a GUI. There was an edit view, correctly created and initialized with a default value. Then the user could enter a value, but whatever the user entered would be ignored.

How did you manage that?

TLDR -- Event structures are my favorite new feature. Try them out and see if you still hate LabView nearly as much. I also suggest not actually using any of your GUI variables. Treat these like declarations and use local variables everywhere else. Otherwise the wires are impossible to trace and buggy to change.

You've probably fixed it, but you can configure it to execute a code block when a value changes with Event structures.

This structure is a little new, but I started LabView before it existed so I only started using it in the last year or two.

It lets you define code to execute based on interrupt style events like "mouse release" on a button whereas in older versions I would wrap all my button checking logic inside of a big timed or while loop because otherwise as you've noted it won't update the value when doing the logic check.

So my old standard style would be that there's a timed loop around each case structure that is checking buttons at 1kHz against a local variable version of the button's boolean, with a sequence inside the case structure that always resets the button state to zero at the end. Otherwise it doesn't check for button presses if one has already been pressed and is running something, or if you have no while/timed loop it doesn't even check at all since it's a run-once program.

LabView patterns are really not very clear, and my least favorite bit is that there's at least ten ways to do anything, and only one or two are good but the others all logically seem like they should work until you look really close.

Edit: Or maybe my least favorite part is that despite being a system designed for instrumentation and controls and data acquisition, my god is it a pain to plot anything.

> How did you manage that?

I probably started coding, and then forgot to finish it ...

(not in LabView to be clear)

Indentation errors in Python can similarly short circuit control flow and are easy to miss for less trained eyes. Disclaimer: I actually love Python.

I guess I'll give an opposing view of LabVIEW since I've worked on and off with LabVIEW over the past 7 years. I don't think it's too different from other text-based languages where it can be turned into a huge mess if the code is not organized properly. This is probably compounded by LabVIEW being targeted towards people who don't start with software backgrounds and don't understand best practices of software design. Using design methods and frameworks like the actor framework (comes with LabVIEW) can go pretty far to develop clean code that can rival or exceed the best examples of text-based source code.

Definitely LabVIEW has it's strong areas though. Anything to do with more complex UIs is probably not something you want to use LabVIEW for. I'd probably say LabVIEW is definitely strongest when paired with National Instrument's hardware (CompactRIO) which gives you access to data faster than you can do with any other system that I've seen. It's also super easy to develop FPGA applications which is a big plus when working with high-frequency data processing.

Overall I think it fills its niche quite well and don't think it's dissimilar to any other language where you can also make a mess of things if you don't know how to best structure the code.

Yep, LabVIEW is just a gateway drug for NI hardware. The integration with their hardware stack is top notch (as you would expect) and can go from scratch to sampling a signal _very_ quickly.

National Instruments does not make (tons of) money with LabVIEW licenses. The real dollars are in their hardware offerings, which are very good, but also very expensive.

The hardware isn't even that good. What you're really paying for is the idiot proofing (i.e., input protection) and the warranties. Which -- even speaking as someone who has designed competing hardware -- is often a good tradeoff.

Interesting. Are you talking about the cRIO line or the PXI one?

My experience with the PXI line was that it was absolutely top notch. I’ve seen some really cool things done with that. Most electrical folks I’ve worked with loved the hardware but absolutely despised the price gouging. They were constantly looking for alternatives yet NI hw remained for most things.

The cRIO line.... it’s getting better and it has improved a ton, but in the early beginnings it was extremely buggy, both hw and software.

I'm mostly referring to the analog sections of a few PXI cards I've looked at. This was in the context of "turn this benchtop prototype built with PXI into a form-factor product". I was surprised at how simple most of it is. There are a couple TI/BB highly-integrated PGA/ADCs that NI gets a lot of mileage out of.

But even if it's not as complex or interesting as, say, a Keithley electrometer, NI's execution really is top notch. Technical brilliance alone does not a product make.

I see. My experience was with medium test stands (couple of thousands of channels) in a more industrial setting, we didn’t really need high-accuracy or specialized ducers (there were maybe one or two of those and we usually wrote custom software for talking to then). Reliable, accurate enough and with strong platform support was killer for us. I don’t think anyone beats NI at that level of integration.

I have done the same. Labview is confusing and destroys computers, old and new.

What I recall from the 90's was using DOS labview to make a control UI and it was pretty remarkable for it's time, clean and lightweight and easy to implement.

When I saw what it had turned into a couple years ago my jaw dropped.

sadly, I think that Python isn't really useful in any ecosystem sort of way last I checked. You probably can ffi the dlls into it, but that's it. In my undergrad days I once did a "UI", then interned at a company with some horrible labview applications... and to this day I am horrified how you can sell this, considering you need ages to setup data processing/IO. 10 lines of Python for doing the same with a webservice/any other data-provider, 100 ones in C - 10 screens with Labview...

It’s really easy controlling most lab equipment using Python. There is good support for GPIO (which most simple instruments are using) and it is also easy to use ctypes to call into external DLLs if you have to. During my PhD I controlled more than 30 different instruments in real-time using Python, so it’s definitely possible. The learning curve is much steeper than for LabView of course if you don’t have experience as a programmer, but in most scientific fields programming is becoming more important anyway so most students learn it.

I use Python extensively in the lab. In addition to what you say, Python plus Arduino is a killer combination. You can use an "advanced" Arduino compatible microcontroller as a GPIO on steroids with real time functionality, then talk to it using a Python program.

While it might be slightly more awkward at first, having to hook up to external DLL's yourself, it really begins to shine when you can integrate it with all of the scientific programming tools such as data analysis and graphing.

don't you mean GPIB?

Yes that was a typo.