4 ms·

Knowing that the ground control software is written in LabView is one of the more disappointing things I've read recently. I did a bunch of test engineering dur

by qchris 6y ago

Knowing that the ground control software is written in LabView is one of the more disappointing things I've read recently. I did a bunch of test engineering during co-ops during college, including multiple "codebases" of LabView, plus the normal class coursework and research lab instrumentation. I hate LabView, to the degree that I made a commitment never to apply to a job that has it's use as one of the requirements or as part of the desired qualifications. I remember working on a getting a brushless motor test stand up and running using a LabView VI, which was written by one of the senior test engineers a couple years before. After spending days working on it, I eventually went to him for help. He sat down with me and it for another two hours, and even then, he needed to take the code (that he wrote!) and go sit down with it alone the next day for several hours to understand what was going on. If you're not working it essentially full-time, on the same codebase, it's insanely difficult to maintain any non-trivial code. What makes the situation even a bigger shame is that National Instruments makes Labwindows/CVI, an ANSI C equivalent to LabView. The few times I've used it (in a graduate-level experimental physics class), it was so much easier to use and maintain.

jccooper 6y ago
That AMA is from 2013, when LabView would have seemed like a more reasonable choice. Dunno if they've changed since then, but it's possible they've come to their senses.
bmitc 6y ago
How well do you actually know LabVIEW? Have you ever used its object-oriented system, actor framework, network streams, or get/set control value by indices (a feature actually implemented for SpaceX) functionalities? These are all things a professional LabVIEW engineer will be familiar with and use. The fact that a system didn't use these means it's either seriously outdated or the person writing it wasn't aware. It sounds like you hate LabVIEW because you worked on a few poorly architected systems, as I don't see anything in your hate for it that actually applies to LabVIEW the language/environment. > If you're not working it essentially full-time, on the same codebase, it's insanely difficult to maintain any non-trivial code. It's hard to maintain any codebase if you're not giving it attention. I would argue that LabVIEW, when properly architected, can be maintained just fine and maybe even easier than other languages. I've done it. LabVIEW is highly performant and excels at throwing data around and processing it and interacting with hardware. Its dataflow nature actually makes it easy to modify and maintain, when done properly. There aren't many languages that make it that easy to make user interfaces and distributed systems. Another language/ecosystem that I would consider for such a system is Elixir/Erlang, but you'll be searching for a user interface solution and lots of hardware drivers. However, with Elixir/Erlang you gain a system even more built for distribution but you lose out a lot on synchronous/sequential performance. C#/F#/.NET are other options to use since NI makes quite a lot of .NET drivers.
- qchris 6y ago
  This is definitely fair--I don't consider myself a LabView expert. I'm proficient with object-oriented systems (Python, C++, Rust (if you consider Rust object-oriented)), with get/set for indices and network streams, but not familiar with actor frameworks outside of a passing read-some-docs a few times. I'd estimate I've cumulatively spent around a month working on LabView full-time, including writing/editing several working instrumentation sets in different settings. I don't like LabView because of the when-properly-architected asterisk. Sure, well-written code doesn't happen all the time in any language, but my personal experience is that the both the frequency and severity of that being the case is much higher in LabView than any other language I've used, making the barrier to entry for writing good code essentially being close to a full-time LabView engineer. You'll get no argument that it can do a good job when it's written well--the good LabView VIs I've used are definitely fast, and as you pointed out, NI makes sure that it plays well with hardware. But, to me, the risk of getting hired somewhere with a poorly-constructed system written in LabView is far too high, considering the grief I've had trying to fix those system. I appreciate your suggestions for other alternatives--I haven't personally used C#/.NET a lot, but I know several test engineers who love it enough to do all their GUI work in it. I'll keep it in mind next time I'm setting up a DAQ system!
  - bmitc 6y ago
    Just a few clarifications. By get/set control values by indices I meant a specific feature in LabVIEW that allows high-performant updates of front-panel controls. You use these when you have a lot of data being streamed to the front panel. By network streams, I again meant a specific LabVIEW feature (https://www.ni.com/documentation/en/labview-comms/latest/data/network-streams/ https://www.ni.com/documentation/en/labview-comms/latest/dat...) for sending data back and forth over Ethernet. It's a nice high-level library that is performant. It just makes it extremely easy to pass data around. In any big system, these features are a must-have. Also, I wasn't judging, so apologies if it came across that way. :) There's just a difference between little small systems that don't use LabVIEW's features and those that do. Most people who have used LabVIEW to its full extent have completely different complaints than those whose experience revolves around university or internship LabVIEW software, and so I like to point out that LabVIEW isn't fundamentally flawed as a visual language. I think that the when properly architected asterisk applies to any language. LabVIEW is in a difficult situation because there are two huge factors at play. It makes it easy to start off and get things going, but systems inevitably grow beyond their original scope, and so LabVIEW systems are often developed by non-software people but still expected to grow. That's a conflict. The second thing is that more traditionally trained programmers have a mental block when it comes to LabVIEW, so people who do know how to properly modularize code don't pay attention to LabVIEW. So in LabVIEW, you have some experts who do treat it seriously, as if it was any other software system, but then a lot of code that was thrown together by others new to software and to LabVIEW. I would say Python is actually in a very similar situation by being "friendly" to beginners, so there is a ton of bad Python code out there. I once interviewed at a place that had completely sworn off LabVIEW. I couldn't get them to explain why. They just hated it. But then I asked to see their Python code, which is what they had moved to, and I was greeted with a single file that was 10,000+ lines long. And in there I saw some function signatures that were 15-20 lines long (yes, the function's arguments spanned that many lines). So I see that as a disconnect. They hated LabVIEW but didn't know why and loved Python and didn't know why. In either case, they didn't know what they were doing. The .NET APIs NI makes are nice enough, and I have used them before but not to a deep degree.
azhenley 6y ago
Having worked at National Instruments, I will say there are some engineers out there that really love LabVIEW. It has been a successful tool.
simontheowl 6y ago
I think another thing that is often overlooked is that a project like this requires a ton of very diverse hardware in the form of hundreds or maybe thousands of sensors, valves, PLCs etc. A rocket launch site reminds me a lot of an industrial process facility. National instruments sells all of that hardware with LabView as a complete solution. Their PXI systems, which are used extensively in the process industry, are quite expensive up-front but the seamless integration of the hardware with Labview drivers, Teststand etc makes it so much more cost-efficient down the line.

by qchris 6y ago

jccooper 6y ago

That AMA is from 2013, when LabView would have seemed like a more reasonable choice. Dunno if they've changed since then, but it's possible they've come to their senses.

bmitc 6y ago

How well do you actually know LabVIEW? Have you ever used its object-oriented system, actor framework, network streams, or get/set control value by indices (a feature actually implemented for SpaceX) functionalities? These are all things a professional LabVIEW engineer will be familiar with and use. The fact that a system didn't use these means it's either seriously outdated or the person writing it wasn't aware. It sounds like you hate LabVIEW because you worked on a few poorly architected systems, as I don't see anything in your hate for it that actually applies to LabVIEW the language/environment. > If you're not working it essentially full-time, on the same codebase, it's insanely difficult to maintain any non-trivial code. It's hard to maintain any codebase if you're not giving it attention. I would argue that LabVIEW, when properly architected, can be maintained just fine and maybe even easier than other languages. I've done it. LabVIEW is highly performant and excels at throwing data around and processing it and interacting with hardware. Its dataflow nature actually makes it easy to modify and maintain, when done properly. There aren't many languages that make it that easy to make user interfaces and distributed systems. Another language/ecosystem that I would consider for such a system is Elixir/Erlang, but you'll be searching for a user interface solution and lots of hardware drivers. However, with Elixir/Erlang you gain a system even more built for distribution but you lose out a lot on synchronous/sequential performance. C#/F#/.NET are other options to use since NI makes quite a lot of .NET drivers.

qchris 6y ago
This is definitely fair--I don't consider myself a LabView expert. I'm proficient with object-oriented systems (Python, C++, Rust (if you consider Rust object-oriented)), with get/set for indices and network streams, but not familiar with actor frameworks outside of a passing read-some-docs a few times. I'd estimate I've cumulatively spent around a month working on LabView full-time, including writing/editing several working instrumentation sets in different settings. I don't like LabView because of the when-properly-architected asterisk. Sure, well-written code doesn't happen all the time in any language, but my personal experience is that the both the frequency and severity of that being the case is much higher in LabView than any other language I've used, making the barrier to entry for writing good code essentially being close to a full-time LabView engineer. You'll get no argument that it can do a good job when it's written well--the good LabView VIs I've used are definitely fast, and as you pointed out, NI makes sure that it plays well with hardware. But, to me, the risk of getting hired somewhere with a poorly-constructed system written in LabView is far too high, considering the grief I've had trying to fix those system. I appreciate your suggestions for other alternatives--I haven't personally used C#/.NET a lot, but I know several test engineers who love it enough to do all their GUI work in it. I'll keep it in mind next time I'm setting up a DAQ system!
- bmitc 6y ago
  Just a few clarifications. By get/set control values by indices I meant a specific feature in LabVIEW that allows high-performant updates of front-panel controls. You use these when you have a lot of data being streamed to the front panel. By network streams, I again meant a specific LabVIEW feature (https://www.ni.com/documentation/en/labview-comms/latest/data/network-streams/ https://www.ni.com/documentation/en/labview-comms/latest/dat...) for sending data back and forth over Ethernet. It's a nice high-level library that is performant. It just makes it extremely easy to pass data around. In any big system, these features are a must-have. Also, I wasn't judging, so apologies if it came across that way. :) There's just a difference between little small systems that don't use LabVIEW's features and those that do. Most people who have used LabVIEW to its full extent have completely different complaints than those whose experience revolves around university or internship LabVIEW software, and so I like to point out that LabVIEW isn't fundamentally flawed as a visual language. I think that the when properly architected asterisk applies to any language. LabVIEW is in a difficult situation because there are two huge factors at play. It makes it easy to start off and get things going, but systems inevitably grow beyond their original scope, and so LabVIEW systems are often developed by non-software people but still expected to grow. That's a conflict. The second thing is that more traditionally trained programmers have a mental block when it comes to LabVIEW, so people who do know how to properly modularize code don't pay attention to LabVIEW. So in LabVIEW, you have some experts who do treat it seriously, as if it was any other software system, but then a lot of code that was thrown together by others new to software and to LabVIEW. I would say Python is actually in a very similar situation by being "friendly" to beginners, so there is a ton of bad Python code out there. I once interviewed at a place that had completely sworn off LabVIEW. I couldn't get them to explain why. They just hated it. But then I asked to see their Python code, which is what they had moved to, and I was greeted with a single file that was 10,000+ lines long. And in there I saw some function signatures that were 15-20 lines long (yes, the function's arguments spanned that many lines). So I see that as a disconnect. They hated LabVIEW but didn't know why and loved Python and didn't know why. In either case, they didn't know what they were doing. The .NET APIs NI makes are nice enough, and I have used them before but not to a deep degree.

azhenley 6y ago

Having worked at National Instruments, I will say there are some engineers out there that really love LabVIEW. It has been a successful tool.

simontheowl 6y ago

I think another thing that is often overlooked is that a project like this requires a ton of very diverse hardware in the form of hundreds or maybe thousands of sensors, valves, PLCs etc. A rocket launch site reminds me a lot of an industrial process facility. National instruments sells all of that hardware with LabView as a complete solution. Their PXI systems, which are used extensively in the process industry, are quite expensive up-front but the seamless integration of the hardware with Labview drivers, Teststand etc makes it so much more cost-efficient down the line.