Hardware engineers – would you rather use a procedural version of labVIEW?
6 points
1 month ago
| 4 comments
| HN
Trying to understand just how convoluted labVIEW's GUI can get. Let's say someone came out with an efficient, procedural, text-based alternative that can integrate with NI hardware - would it be a no-brainer switch?
basementcat
1 month ago
[-]
When I used to use LabVieW (shudder) I usually just made a VI to call python or C/C++.

A large LabView project can become tricky to maintain. Two of the largest LabView code bases are the flight software for NASA's Cold Atom Laboratory and SpaceX's real-time launch visualization GUI and both may have required substantial support from National Instruments.

reply
gazgaz
1 month ago
[-]
Any pitfalls with python or C/C++ i should be aware of? Agree that a large labview project is quite tricky
reply
basementcat
1 month ago
[-]
A few issues come to mind (I'm sure there are others.)

1. LabView doesn't (or didn't) really mesh well with things like git or mercurial so care must be taken making sure the C, C++, Rust, Python remain coupled with corresponding versions of LabView VIs.

2. Sometimes there is a cultural gulf between the LabView developers and the C, C++, Rust, Python people. E.g. SpaceX may have some fun integrating California Software (C++, Rust, Python) with Texas Software (LabView)

3. If you only have a limited number of LabView license seats, make sure your CI automata doesn't eat all of your licenses.

reply
instagib
1 month ago
[-]
Matlab works fairly well.

Labview is a quick and dirty let’s do this and forget what happened. I considered looking up how to do something correctly then my second thought was to do whatever and turn it into a sub to hide the work.

reply
SonOfKyuss
1 month ago
[-]
Isn’t that what Measurement Studio is meant for?

https://www.ni.com/en-us/shop/product/measurement-studio.htm...

reply
farseer
1 month ago
[-]
Yeah that procedural text based alternative is called Python.
reply