NI LabVIEW Supports Multiple Targets and Operating Systems

Avoid Lock-In with Support for Multiple OSs

One of the big benefits of programming with a high-level tool such as LabVIEW is a layer of abstraction between the developer and the underlying OS and computer hardware complexities. One practical upshot is that adopting LabVIEW does not tie you to a particular OS or family of OSs. LabVIEW development systems are available for Windows, Mac, and Linux OSs, and you can run LabVIEW code on all three, as well as on dedicated real-time OSs.

Some languages and frameworks are available for or viable on only one OS due to vendor restrictions. This might require purchasing new tools, retraining, and porting existing code to a new language on the new platform. Other languages are cross-platform, but because they rely on the developer to call into OS functions for operations such as memory allocation, file I/O, and hardware access, which tend to differ between systems, any real application ends up being tied to the OS it was developed for. In this case, you would need to learn the specifics of the new system and rewrite much of the existing application.

Code you write with LabVIEW is far more portable; because you rarely call the OS directly, you don’t need to be an expert in every OS you wish to target. Most LabVIEW applications are cross-platform and can be taken to different OSs without major modifications. Because different platforms do have different capabilities and hardware drivers, some features may not be available on every OS – however, these differences are noted in the LabVIEW Help file and are generally minor modifications rather than wholesale changes.

Operating System	Versions	Notes
Windows	XP Vista 7	64-bit LabVIEW is available for 64-bit versions of Windows Vista and 7. Windows XP 64-bit is not supported.
Mac	OS X 10.4 or later
Linux	Red Hat Enterprise Linux WS 3 Mandrake Linux/Mandriva 10.0 SuSE Linux 9.1	Linux kernel 2.2.x, 2.4.x, or 2.6.x, for the Intel x86 architecture, GNU C Library (glibc) Version 2.2.4 or later
Real-Time	Phar Lap VxWorks	VxWorks only supported on CompactRIO targets.

Table 1. LabVIEW OS Compatibility

View the NI LabVIEW Operating System Support Roadmap for current and future support information.

Many Hardware Targets, One Development Environment

Figure 1. Multiple Hardware Targets

 

Not only does LabVIEW offer you the freedom to move between OSs, your skillset as a developer moves from target to target as well, because it is the same toolchain and programming paradigm. Using a cross-platform, cross-target tool makes LabVIEW developers more versatile

Test and control systems often have multiple components that may run on different hardware. The human machine interface (HMI) could be a touch panel computer or a desktop PC. The test code could be running on an industrial controller or embedded PXI system. You might have critical logic running on a rugged real-time PC or field-programmable gate array (FPGA) board. You may also require intelligence embedded into an instrument, machine vision system, or wireless sensor.

Programming and setting up these diverse systems is a challenge with traditional tools.

Traditionally, you needed a team of experts to tackle the various programming elements. You needed some combination of a high-level math or engineering language expert to develop the algorithms, a GUI or host application developer (perhaps a C++, C#, or Visual Basic expert), an embedded programmer (probably C, or some variant), and, finally, someone to program the FPGA (VHDL and Verilog being the most common languages). You also probably needed knowledge of another scripting language to handle converting data and tying all the components together. At least four different skillsets and knowledge of four different languages and toolchains were required to solve a problem that can be solved by one skilled LabVIEW developer.

With a LabVIEW development system, you can develop and deploy on PCs and industrial controllers running regular desktop OSs. Deploying to more specialized hardware requires the appropriate add-on module in addition to a LabVIEW development system.

• LabVIEW Real-Time Module
• LabVIEW FPGA Module
• LabVIEW Touch Panel Module
• LabVIEW Embedded Module for ARM Microcontrollers
• Vision Development Module for LabVIEW
• LabVIEW Wireless Sensor Network Module

Enabling Graphical System Design

By keeping development for multiple targets in the same toolchain, you can rapidly prototype because you spend less time handshaking between tools and individuals. With several developers, a typical system design process may look something like this:

Figure 2. Multiple Roles in Traditional System Design

 

Smaller development teams may require individuals to fill multiple roles and possess multiple skillsets. Moving between tools inevitably requires additional work to write new code, prepare generated code for the new target, and communicate data between those targets. Time spent performing this kind of software housekeeping is essentially wasted and may actually take longer than working on the actual application you are trying to build. Each additional step and tool increases the overall project scope, introducing more elements that could potentially go wrong. Worse yet, this unproductive work must be repeated for each design iteration, leading to unnecessarily long design cycles and longer time to market.

Figure 3. Traditional System Design Housekeeping

 

The LabVIEW graphical system design approach empowers a much smaller group of domain experts by channeling one skillset and toolchain across multiple disciplines. The housekeeping work required to move code between targets really doesn’t differ much from application to application – it’s simply overhead caused by incompatible or poorly integrated tools. Because LabVIEW handles cross-compilation, targeting, and data transfer, your domain expertise remains closer to the prototype. Consequently, design cycles become much shorter, and you can iterate on your ideas faster.

 

Figure 4. One Expert in Graphical System Design

 

The technical complexity of the problem doesn’t change between the two approaches. When you take your LabVIEW-developed algorithms and code and deploy to an embedded target, LabVIEW handles all of the packaging, compiling, and deploying. You, as the developer, are not exposed to all of the low-level cross-compilation or target-specific optimization that you would be otherwise. LabVIEW also contains several mechanisms to facilitate communication between the various components so you don’t have to implement complex protocols such as DMA or network streaming to move data around your system.

Developing a GUI for your application is often an afterthought in many legacy tools. LabVIEW, on the other hand, associates a GUI with every function and subcomponent. For many parts of the application, such as those running on embedded targets, the GUI is simply a powerful debugging tool. For the host or HMI application, the GUI is an important element that you would otherwise have to implement separately.

LabVIEW and off-the-shelf NI hardware represent a perfect prototyping and low-volume deployment platform. When high volume or specific form factor needs necessitate custom hardware, you can still use the NI hardware as a prototyping platform and then move your proven algorithm design to your custom hardware.