4 ms·

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

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

by qchris 6y ago

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.