If you’re not a software developer but need to make quick measurements using real instruments – this requires little programming experience. However, to be clear, coding with LabVIEW requires you to follow good programming practices just like any other programming language. Like with any other programming language, garbage in equals garbage out.
If you need tight integration between software and measurement/control hardware. LabVIEW has two targets that allow synchronization between measured inputs and calculated outputs. The first has on the order of 1 ms jitter and uses LabVIEW RT. The second has jitter on the order of 1 ns jitter and uses LabVIEW FPGA.
Because your company is already heavily invested in the ecosystem – I know this sounds sort of like a “if Billy jumped off a bridge” analogy, but it’s not. While this isn’t my favorite reason to use LabVIEW, pragmatically, LabVIEW is a tool, and if your company is already heavily using this toolset, then you may be doing more harm than good by creating a separate parallel toolset to have to work with. Now you need to maintain multiple environments and maintain the expertise in two toolsets.
It’s well-supported within the test & measurement community – from toolkits, to instrument drivers, to consultants that can step in if your main LabVIEW guy unexpectedly decides to leave your company.
The development environment is user friendly.
National Instruments works hard to make the LabVIEW development environment consistent across hardware platforms, from PCs running Windows to embedded controllers running a real-time Linux OS with connections to FPGAs for tight synchronization I/O. Most differences are included to take advantage of the resources of the specific platform so that the learning curve between platforms is about as small as it can get.
The data flow paradigm inherent in LabVIEW makes coding parallel operations trivial.
Each VI, which would be called a function in most other languages, comes with a user interface and a code block. Since you create a user interface for each function, debugging is much more visual than using user-defined breakpoints and probes.
LabVIEW’s brings together all the code, hardware, and build definitions into one location under the Project Window.
Another closely related question that you might want an answer to is “What is LabVIEW used for?”. This article explains the main applications that LabVIEW is used for, with case studies, how LabVIEW interacts with the real world, and what hardware LabVIEW runs on. If you need LabVIEW help and want to know what your options are, check out this article on LabVIEW Help – What are my options?.