5 ms·

I have led the eviction of LabView from three different engineering organizations now. It’s seductive how easy you can get started with building a bench top sys

I have led the eviction of LabView from three different engineering organizations now. It’s seductive how easy you can get started with building a bench top system. Then it grows from there and pretty soon people are doing linear algebra and trying to automate tests by writing data into a database - screen after screen of multiply nested windows. It’s not pretty, it’s not fast (you need a much more powerful computer to run LabView than a comparable Visual C++ or Matlab program). It’s also very hard to document it well, really hard for a third party to bootstrap into your code base, doesn’t play well with common version management tools, requires a full license for every machine you run it on, and if your developer leaves, it can be hell to hire someone to maintain it - LabView consultants cost a mint and are hard to find. We had a bake-off once, once you have the instrument control DLL’s and link them into Matlab, you can code up a new experiment in Matlab in about 10% of the time it takes to do the same thing in LabView. And from there, you can do pretty much anything that needs doing in terms of data work-up. I’m sure these days you could do the same in Python, which has become the new science and engineering language.

globular-toast 6y ago
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.
- ironmagma 6y ago
  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.
  - hodgedual 6y ago
    Any compiler or linter would likely complain about unused variables or code in such a situation.
    - benibela 6y ago
      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.
      - neltnerb 6y ago
        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.
fock 6y ago
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...
- ThePhysicist 6y ago
  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.
  - analog31 6y ago
    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.
  - technologic 6y ago
    don't you mean GPIB?
    - ThePhysicist 6y ago
      Yes that was a typo.
exmadscientist 6y ago
> 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.)
- w_t_payne 6y ago
  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.
  - kisna72 6y ago
    Honestly .. I would love for this to happen.
  - neltnerb 6y ago
    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?
  - 6y ago
ThePhysicist 6y ago
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).
cmos 6y ago
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.
sakian 6y ago
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.
- elteto 6y ago
  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.
  - exmadscientist 6y ago
    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.
    - elteto 6y ago
      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.

globular-toast 6y ago

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.

ironmagma 6y ago
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.
- hodgedual 6y ago
  Any compiler or linter would likely complain about unused variables or code in such a situation.
  - benibela 6y ago
    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.
    - neltnerb 6y ago
      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.

fock 6y ago

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...

ThePhysicist 6y ago
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.
- analog31 6y ago
  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.
- technologic 6y ago
  don't you mean GPIB?
  - ThePhysicist 6y ago
    Yes that was a typo.

exmadscientist 6y ago

> 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.)

w_t_payne 6y ago
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.
- kisna72 6y ago
  Honestly .. I would love for this to happen.
- neltnerb 6y ago
  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?
- 6y ago

ThePhysicist 6y ago

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).

cmos 6y ago

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.

sakian 6y ago

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.

elteto 6y ago
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.
- exmadscientist 6y ago
  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.
  - elteto 6y ago
    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.