Archive for the ‘labview’ Category

Today’s post is part of a series exploring areas of focus and innovation for NI software.

Phillips headshot.jpg


Today’s Featured Author

Jeff Phillips considers LabVIEW as essential to his day as food, water, and oxygen. As senior group manager for LabVIEW product marketing at NI, Jeff focuses on how LabVIEW can meet the changing needs of users. You can follow him on Twitter at @TheLabVIEWLion.




This past Saturday, I was watching the Disney Junior television series Jake and the Never Land Pirates with my daughter. After 473 straight episodes, my mind started to wonder toward unfinished business at work. As my subconscious carried my mind back to my computer, I heard Captain Hook yell at the bumbling Mr. Smee “time is everything!” after the first mate spoiled yet another impossibly ridiculous attempt to trap the antagonist pirates. That got me thinking about a UX review we were doing at work related to “time to first measurement” design flows in LabVIEW.


The concept of time plays many roles within LabVIEW, but perhaps the most important to the highest volume of LabVIEW users is the time it takes to get to data. A few weeks ago, I visited with an account who, despite being an avid and very experienced programmer, asked to see the ability to access data without the requirement of writing code. LabVIEW has proven to be an amazing tool for developing code to automate the acquisition, analysis, and presentation of measurement data. However, there are three key areas that we’re focusing on to improve LabVIEW as a general data acquisition tool.


No Requirement to Program


Amongst the purists, there’s an age-old debate over whether LabVIEW is a tool or a programming language. Make no mistake. LabVIEW is a tool that was specifically designed to give the engineering community the ability to interface with the world around them through PC-based hardware. At the core of LabVIEW is G, a graphical dataflow language that uses abstracted blocks to represent functional logic and physical wires to transport data between those blocks. Although I believe with every fiber of my being that G (inside of LabVIEW) is the best and most efficient way to develop automated measurement applications, there are many times that you just want to get the data and don’t care about doing so over and over. We’re working on some unique UX flows within the product that give you the ability to move from seeing the hardware to getting the data without needing to write code on the block diagram.

Capture (1).PNG


Improved In-Product Configuration


I touched on this a bit in a previous article, but you should be able to discover your hardware inside of LabVIEW without a secondary improvements to LabVIEW. From the discovery of hardware to thedeployment of code to it, your one-stop shop for that experience is being designed into LabVIEW. Measurement & Automation Explorer. This is a key tenet as we prioritize our improvements to LabVIEW. From the discovery of hardware to the deployment of code to it, your one-stop shop for that experience is being designed into LabVIEW.

Capture (1).PNG


Improved Driver Discoverability

The third key area is driver installation. In the modern era, we are all typically used to having our device either find its driver automatically or come preloaded with it. As I envision a perfect future, I see a world where LabVIEW, as a “hardware-aware” tool, can automatically detect the driver you need, automatically determine the version that is compatible with other hardware interfaces in the same system, go find that version, and install it in real time.

Capture (1).PNG


Of course, the concept of time extends far beyond this instantiation in LabVIEW. LabVIEW is the only measurement software with a waveform data type that propagates the concept of time throughout a compile chain. LabVIEW is the only measurement software with a Timed Loop—a logic flow that is controlled by either a hardware clock, rising or falling edges of a digital signal, or even the predetermined close rates of an OS itself. From saving you time in your day-to-day job to exposing the elusive concept of time in a highly synchronized and distributed application, LabVIEW is designed from the ground up (and being improved inside and out) to continue down this path.


We’re not forgetting about a mortal enemy by the name of Tick-Tock the Croc. Tick-tock, tick-tock.

Today’s post is part of a series exploring areas of focus and innovation for NI software.

Time: a precious commodity. It’s even more precious when talking about your own time.


Wikipedia, as usual, provides an enlightening perspective: “Time has long been a major subject of study in religion, philosophy, and science, but defining it in a manner applicable to all fields without circularity has consistently eluded scholars. Nevertheless, diverse fields such as business, industry, sports, the sciences, and the performing arts all incorporate some notion of time into their respective measuring systems.” NI is no different than this generic definition. We heavily incorporate time into our respective measurement and control systems.


A Brief History of Time is a favorite among the NI team in part due to our intimate history with time—both in our own engineering and within our products for other engineers. We were among the first in test and measurement to effectively implement time into products. For decades, LabVIEW has incorporated time in native G programming concepts. We first introduced real-time system integration (RTSI) for measurement timing and synchronization in our PCI DAQ products wherein LabVIEW  and the NI-DAQmx driver rout the RTSI automatically.  Additionally, we are one of the only major test and measurement vendors to offer a PXI timing and synchronization product line (for PXI, RTSI is built into the backplane). Through shared timing and synchronization, you can vastly improve the accuracy of measurements, apply advanced triggering schemes, or synchronize multiple devices to act as one for extremely high-channel-count applications.


Internally, we refer to “time” as a “first-class citizen” of our platform. Engineers benefit from this “first class-ness” every day. You see this elevated status in applications like the world’s first real-time optical coherent tomography (OCT)  imaging system to enable early cancer detection. This application uses LabVIEW and PXI for OCT and combines 320 simultaneous channels at 10 MS/s while LabVIEW performs >700,000 FFT/sec. Time is also a major player in controlling the world’s largest telescope. With 1.87 teraflops of data, 64 compute notes at 512 cores, and 14,000 samples every 2 ms; time matters. The Large Hadron Collider (LHC) at CERN is also taking full advantage of NI’s complex timing capability.  The LHC is a complex of interconnected circular and linear accelerators. All devices that serve the accelerators (magnets, kickers, and more) must be precisely synchronized and controlled by a central control system. CERN adopted LabVIEW FPGA to serve as the timekeeper for more than 100 collimators. Inside the collimators, LabVIEW performs collimator control for approximately 600 stepper motors with millisecond synchronization over the 27 km of the LHC.


However, this blog series as I hope you know by now, is about where we are investing in our products. With new technologies, we know we can significantly improve your ‘first time to measurement’ AND complex mastery of time for highly distributed, synchronized, heterogeneous systems.


Time to First Measurement

Our insatiable need for instant gratification translates directly to our measurement and control systems. When you plug in your DAQ device or myRIO, you want to see data immediately to not only know that everything is working properly, but to gather information and insights as quickly as possible. We are currently exploring a scalable use-model of “interactive panels” to ensure you have instant access to measurements, as well as approachable and interactive analysis in a manner that integrates seamlessly into your G experience when you need to automate.




Figure 1. Interactive panels will provide instant data access, visualization, and options for exploration.

Time-Sensitive Networks

Building on our leadership in measurement and control, we are participating within the IEEE 802 standards group and the AVnu Alliance to help define the Time Sensitive Networks (TSN) standard. TSN will be part of the next revision to standard Ethernet technology and will provide a standard mechanism for network-based clock synchronization, high reliability using bandwidth reservation and path redundancy, and bounded latency enabling network-based, closed-loop control.   This evolution of the Ethernet standard is essential for LabVIEW-based system design tools and will enable creation of distributed, coordinated measurement and control systems that will be heart of the industrial internet of things.




Figure 2 - Distributed control system paradigm shift 1974 to 2016 and beyond.


You—the engineers and scientists of the world—are solving the grand challenges, and you need time. You need time so that your measurements and control algorithms are correct and synched. You need time so that you have an accurate reference for analytics, insights, and correlations. Most importantly, though, you just plain need time. You need YOUR time to tackle those grand challenges in the most efficient and effective manner possible. Oh, and getting some of your time back means you can enjoy a little more of that thing called life; but that’s in another blog. 


Until next time…


Shelley Gretlein Headshot


Today’s Featured Author

Shelley Gretlein is a self-proclaimed software geek and robot aficionado. As NI’s director of software marketing, you can find Shelley championing LabVIEW from keynote stages to user forums to elevator conversations. You can follow her on Twitter at @LadyLabVIEW.

Today’s post is part of a series exploring areas of focus and innovation for NI software.

System Configuration

Home, Business, and Engineering | The Gauntlet Accepted


Regardless of whether your background is in hardware, software, or no-ware at all, systems management and configuration—that line integrating hardware and software into systems—is always a pain point and major productivity drag. In the business world, systems configuration tends to fall under the purview of the oft-maligned IT organization. In the home world, systems configuration falls to the most technical family member. We’ve all received the dreaded “home help desk” call from friends and family alike. Within the engineering domain, I am ashamed to admit we are well behind IT in terms of formalizing the configuration, provisioning, management, and maintenance of integrated hardware and software systems. It is thus our natural imperative as competitive engineers to address the unnatural gap between IT and engineering. 


All kidding aside, IT organizations have in their toolbox a bevy of excellent and mature OSs, including Linux, Mac, and Windows, plus a large range of productivity tools and frameworks for managing the deployment and configuration of devices such as servers, PCs, laptops, tablets, printers, phones, and a vast array of peripherals. Of course, life took a turn for the complex when mobile and cloud trends fractured the Wintel Duopoly, and the IT industry has scrambled to keep pace with both the era of “bring your own device” and the cost-saving cloud. In comparison with IT, scientists and engineers have historically lacked the equivalent toolbox for managing our systems. Specifically, we lack an “Engineering OS” and IT-scale systems management frameworks.

The Engineering Operating System | The Foundation


OSs at their core provide key abstractions to computing hardware and standard APIs for driver and application software. Through its standardization of driver APIs across a wide array of devices, one of the most basic value propositions Microsoft provided in its early days was the near certainty that your mouse, display, keyboard, and printer would all integrate and function well. While the bar for general purpose OSs has obviously evolved a bit for “standard” peripherals, the sheer breadth and irreducible complexity of purpose-built engineering systems has not kept pace. NI has a long history in providing “key abstraction to computing hardware” and “standard APIs for driver and application software.” 


Over the last few years, we have redoubled our energy seeking to standardize on an open set of APIs for device and target discovery, visualization, exploration, configuration, and state management. It is our goal to provide these first-class APIs for our own hardware as well as to integrate broader ecosystems of hardware. We also recognize the value of the mature IT standards and of the general-purpose OSs. Combining these elements, we have three key philosophies for our recent efforts which you will see in the market place over the next few years:

  1. APIs First | Build public APIs to all our services then layer our UIs on the same APIs that we want our community to use
  2. Leverage standards
  3. Be IT-friendly

Hardware Aware and System Visualization | Innovate on the Foundation


With our engineering OS providing us the core APIs for managing many different kinds of engineering devices, we foresee a great opportunity to innovate on the state of the art in systems management relative to both IT and engineering. LabVIEW has always been a hardware-aware design environment, but we are looking to greatly increase the degree of hardware and software integration as well as radically improve the scale of devices and systems that we can manage. Over the last few years, we have directly integrated the hardware state into our core compiler. That is, just as LabVIEW has a rigorous syntax checker for our programming languages, we will also provide a syntax checker for the hardware that validates not only the basic hardware settings, but also validates that those settings are correct for a given software application. In essence, we will validate the software syntax, the hardware syntax, and the hardware/software syntax using the same compiler techniques we have evolved over the last 20 years. By doing this, we provide you with a unified design environment speeding your development of systems and accelerating your debug and diagnostic cycles at all phases of design, development, deployment, and maintenance.



LV Comm System Designer_FIFO DataLink ss.png


In addition to the seamless hardware state management, we are looking to revolutionize how engineers design large systems of many devices and manage the interconnections of all system elements ranging from sensors and actuators to network connection of multiple embedded devices.     For our time-critical measurement and control systems, we need to understand the tradeoffs of different networks, buses, and I/O choices. Sorting through the implications of these design space tradeoffs can be complex and often involves tedious review of web sites, product manuals, and hardware specifications. We believe we have created a world-class visual canvas that elegantly, quickly, and fully describes your system topographies the way you would like to see them and at the same time is the input language to our hardware-aware compiler. From this system design canvas, you can rapidly explore hardware capabilities and make your key design time tradeoffs optimizing size, bandwidth, latency, compute power, and price. 


Very practically, we have found our system design canvas serves as a living specification document for a system and provides a simple and natural place to integrate all of the hardware and system-related documentation ranging from performance specifications to pin outs. All of this can be integrated into different types of generated documentation to describe your system to developers, system administrators, technicians, or even your customers.



As application needs grow in size and complexity, our systems management tools must also scale to deal with large systems. In the 80s and early 90s, a large-scale NI system might include one PC, an SCXI chassis, and a few hundred DAQ channels. Today, we have some installations with thousands of CompactRIO devices, tens of thousands of I/O channels, and their associated sensors and actuators. We are radically innovating in how we leverage large-scale servers and the cloud to administer and manage so many devices. Within our engineering OS, we are building out IT-friendly security, logging, system health, diagnostic and administration services.  At this level of scale, the often separate worlds of IT systems management and engineering systems management merge.  Now that they do, we plan to be excellent corporate and secure global citizens connecting our engineering ecosystem to the business ecosystem.


Because the LabVIEW design environment leverages our engineering OS, as we scale it out to servers and the cloud, your applications and systems get the same scaling benefit. We are maniacally focused on ensuring that the LabVIEW editor provides you the right experience for productively managing these extremely large scale systems and are ensuring that nearly EVERY editing operation supports “batch edits” on a near limitless number of VIs, devices, targets, or any element of your system that is configurable.

In Conclusion


We believe engineering systems management is ready to transition from a long standing pain point to a key accelerator in your productivity. We believe the systematic integration of IT-friendly standards, general-purpose OSs, and the right engineering OS sets a foundation for managing all of the elements of your system. Further, we believe key innovations in hardware-aware design environments, hardware design space exploration, system visualization, and massive scalability will radically alter our collective ability to solve the most complex and demanding engineering problems of our time.


Fuller headshot.jpg



Today’s Featured Author

David Fuller has nearly 20 years experience in software engineering and is currently NI’s vice president of application and embedded software. You can’t follow him on Twitter because he’s a software engineer.

Today’s post is part of a series exploring areas of focus and innovation for NI software.


Jeff_LV1.0_Block Diagram_ss.jpg

An internal goal at NI is to be a trusted advisor for engineers. In many cases, this perspective has focused on translating emerging technology trends into meaningful know-how for you, regardless of our products’ involvement. Microsoft’s switch from XP to Vista, multicore processing, and now the Internet of Things are examples where NI has partnered with industry leaders, including Intel and Microsoft to ensure that you understand the impact these trends had, or will have, on you.


Another example is field-programmable gate array (FPGA) technology, which is quickly becoming broadly relevant for both test and control applications. The FPGA silicon provides a rare combination of high-performance throughput and ultimate reliability, with a purely digital logic implementation that eliminates the need for an embedded OS. The main challenge of the FPGA, however, is how incredibly difficult it is to program. Currently, programming an FPGA requires a low-level language such as VHDL or expensive and unreliable code conversion utilities.


The LabVIEW graphical dataflow paradigm maps perfectly to the FPGA architecture. The primary attraction that LabVIEW provides for FPGA programming is abstracting a low-level programming paradigm into a high-level graphical representation. Even with that abstraction, LabVIEW users are telling us that:


  1. ) Mapping algorithms to the FPGA requires many iterations of manual code re-writes
  2. ) Compile times are long
  3. ) Performant applications still require an intimate knowledge of the FPGA architecture


As I’ve mentioned before, there are several investments we are making with LabVIEW (previously I’ve discussed UI and UX) to bring back the level of innovation that you expect. The newly-announced LabVIEW Communications System Design Suite brings to market a redesigned FPGA compiler that addresses all of the issues above. This new FPGA compiler is designed specifically for algorithm designers looking to map theoretical floating-point math to the FPGA. However, there are several components that you can apply more broadly, such as these three key innovations:


  1. ) A data-driven float-to-fixed compiler
  2. ) The multirate diagram, a new dataflow-based model of computation that enables the synchronous execution of code at varying rates
  3. ) A built-in profiler that provides compile recommendations based on input parameters - such as desired throughput


This redesigned FPGA compiler is indicative of the level of innovation going into LabVIEW. Although LabVIEW Communications is designed specifically for wireless prototyping, the majority of the innovation can be broadened to a much larger portion of the existing LabVIEW user base.


Review the features of LabVIEW Communications today.


Phillips headshot.jpg


Today’s Featured Author

Jeff Phillips considers LabVIEW as essential to his day as food, water, and oxygen. As senior group manager for LabVIEW product marketing at NI, Jeff focuses on how LabVIEW can meet the changing needs of users. You can follow him on Twitter at@TheLabVIEWLion.

Shelley Intro Image.JPG

I’m going to contradict myself in this month’s blog post. I don’t use clichés much, however I (usually) find them to be accurate and descriptive. (Note: because most clichés have become trite or irritating, we often forget that their novel origin was based in truth). Let me take you back to when I started at NI.


In the late ‘90s, reprogrammable silicon was considered mainstream across consumer, automotive, and industrial applications. Based on the critical invention of the XC2064 FPGA by Freeman and Vondershmitt, the FPGA was becoming a coveted technology for the compute power, field-upgradability, and performance capabilities. However, tools to program the FPGA prevented domain expert access: creating a technology that was too good to be true. Or so I thought.


In 2001, I began working with an in-development product we had demoed at NIWeek a few years earlier, but hadn’t released yet. This not-so-secret project, code named “RVI” or reconfigurable virtual instrumentation, was a graphical design approach to programming an FPGA. Having a computer science and math background, abstract and software-centric is more comfortable and familiar to me than meticulous hardware design. So the idea that you (or even a CS-person like me) could abstract a ton of silicon details and program the hardware with a productive tool like LabVIEW (rather than an HDL) seemed impossible.


This is where the contradiction begins. It wasn’t too good to be true; the cliché was wrong. It was good AND it was true. Luckily, I could rely on another well-known phrase used at NI to describe the innovation taking place: “the genius of the AND” inspired by author Jim Collins. With productive, graphical programming; system abstraction; AND hardware design for dedicated determinism including 25 ns I/O response, protocol customization, and rapid prototyping, LabVIEW FPGA breaks the cliché.


I’m not the only geek who gets excited about this capability. Stijn Schacht of T&M Solutions took advantage of the control accuracy of an FPGA to lift 20-metric-ton unbalanced trays of uncured concrete more than 6 meters while maintaining a strict accuracy of two millimeters. Because he used LabVIEW to get that precision from the FPGA, his team developed an application in only two months and was able to reuse the modular code for their next project.


Kurt Osborne at Ford Motor Company is a believer as well. Ford used LabVIEW FPGA to design and implement a real-time embedded control system for an automotive fuel cell system.


LabVIEW Communications.png

The LabVIEW Communications environment enables an entire design team to map an idea from algorithm to FPGA using a single high-level representation.


So what’s next? I encourage you to explore the latest cliché contradiction that takes FPGA design to the next level – LabVIEW Communications System Design Suite.


LabVIEW Communications is a complete design flow (with bundled software defined radio hardware) for wireless communications algorithms. This suite includes everything from an integrated FPGA flow, to an HLS compiler, to a new canvas (Multirate Diagram) for streaming algorithms, and an innovative way to explore your hardware system with the NI System Designer. The genius of the AND lives on in LabVIEW Communications.


Explore the latest cliché contradiction today at


Shelley headshot.jpg


Today’s Featured Author

Shelley Gretlein is a self-proclaimed software geek and robot aficionado. As NI’s director of software marketing, you can find Shelley championing LabVIEW from keynote stages to user forums to elevator conversations. You can follow her on Twitter at @LadyLabVIEW.

The level of hazard for all radioactive nuclear waste diminishes with time, so to protect public health and the environment it’s important to construct containers that won’t fall apart as they age. In order to develop a measurement system to provide insight on long-term nuclear storage, ProtoRhino researched copper cracking mechanisms using FlexRIO and LabVIEW.





ProtoRhino used FlexRIO and LabVIEW to measure the mechanics of copper cracking under stress in a millisecond timescale. The nuclear waste containers must last 10,000 years and retain their integrity under geological stress and corrosion. LabVIEW was used to program the FPGA. The FlexRIO was used for image processing and the collection of data generated from testing the copper’s deformation under stress. By monitoring the cracks in the copper, ProtoRhino may soon be able to find a safe nuclear waste container, which is key to environmental protection and pollution prevention.


>> Read the full case study.

In most LabVIEW applications, the front panel of a subVI is displayed in order to retrieve inputs from the user, or to simply display information. By following these steps, brought to you by Darren Nattinger, you can make your subVI panels easy to develop and debug.

1. Handle the opening and closing of the subVI panel programmatically. Many LabVIEW users choose to use the SubVI Node Setup right-click option to display the subVI panel. But the downside to this option is that your subVI won’t run any initialization codes before displaying its panel. To bypass this problem use the FP.Open method to display the subVI panel once you have initialized it, and use the FP.Close method to close it once the user dismisses the subVI dialog.



2. Configure the VI Properties of the subVI properly. Set the Window Appearance in VI Properties to "Custom” and customize your settings to match the image below. As you can see there are various setting changes, in particular the “Show Abort Button” option is disabled to prevent users from closing your entire application by pressing Ctrl-. while your subVI dialog is active.




3. Call your modal dialog subVI dynamically. Whenever you run a VI, all of its subVIs are reserved for running, which means none of the subVIs are in edit mode. Any reserved subVI that has a modal window appearance will immediately be displayed if its front panel is already open. Since it is a modal window, you cannot dismiss it because it's reserved for running. The best way to avoid this problem is to call the modal dialog subVI dynamically by changing the subVI to “Load and retain on first call.”



>> Get more LabVIEW tips from Darren.

Today’s post is part of a monthly series exploring areas of focus and innovation for NI software. term “user interface” doesn’t adequately capture the depth of experiences we have while interacting with today’s mobile and desktop computing platforms that serve as portals into the evolving virtual world. Personally, I have never been more motivated by the trends in computing platforms with the web and cloud and radical innovations in UI ranging from touch to advanced visualizations of massive amounts of data. However, the fracturing of the Wintel monopoly creates a challenge for software developers of all kinds to be able to develop solutions that can reach all customers on all of the screens they use.

There isn’t really one technology that can deliver native, first-class experiences on all mobile platforms, all web platforms (aka browsers), and all operating systems. We are faced with a clear cost versus reach versus “native-ness” tradeoff.

It’s interesting to watch as key technologies like HTML5 rapidly adapt their core capabilities and browser vendors continue to optimize the performance of their JavaScript engines. There is massive potential in these rapidly improving Web technologies with strong use cases that not only provide traditionally-oriented controls and indicators for data visualization, but also have the power to support full “sovereign” capabilities like rendering and even editing LabVIEW diagrams themselves.

You can’t really talk about Web front ends without acknowledging the back-end server or cloud infrastructure with which the front end communicates. When NI looks at the world through the lens of acquire, analyze, and present in the context of the Web, we naturally map our presentation layer of VIs and controls and indicators to elements within the browser. However, the acquisition, storage, and analysis functions need to run server-side and server-side at scale with Big Data, or as we like to say, Big Analog Data. We are creating IT-friendly, server-side middleware that can manage the acquisition and storage of Big Analog Data and then provide Web-friendly APIs to that data so customers can quickly create VIs to visualize and analyze the data.

We are not only seeing massive shifts on the Web UI front, but also with mobile and tablet experiences, specifically around touch. For a language like LabVIEW, predicated on direct manipulation and a rich visual and spatial interaction model, we see a clear match between touch-enabled platforms, graphical programming, and interacting with your data.

We feel LabVIEW is the most touch-ready language on the planet and we think the best way to interact with controls and indicators for data visualization is also touch-based. Thus, we want to enable touch-based features for LabVIEW and touch-based features for your VIs. 

Today, the NI R&D team is simplifying a version of the LabVIEW editor, in collaboration with LEGO, which is touch-ready and tablet-friendly. The early prototypes in the lab are a delight to use and when you see and use it, I hope you agree. NI is well suited to map the beneficial evolutions of UI capabilities on the Web and in touch to engineers, scientists, and students and are working hard to do exactly that.

Stay tuned as we discuss more features the NI team is exploring for updates to NI software.


Fuller headshot.jpg

Today’s Featured Author

David Fuller has nearly 20 years experience in software engineering and is currently NI’s vice president of application and embedded software. You can’t follow him on Twitter because he’s a software engineer.

Today’s post is part of a monthly series exploring areas of focus and innovation for NI software.


Jeff_LV1.0_Block Diagram_ss.jpg

The introduction of LabVIEW to the market was defined by a revolutionary graphical user interface that included a combination of built-in libraries for engineering applications and a drag-and-drop UX schema. I’ve heard stories from the “original” generation at NI regarding the jaw-dropping nature of LabVIEW in the early 80s and 90s due primarily to the simplicity of the development of the UI. Of course, 30 years ago the Internet didn’t exist, cellular networks were a novel idea for military applications, and touch-screen tablets were a distant dream.

For decades, the GUI set LabVIEW apart from traditional programming languages for two reasons. First, the UI components were built into the environment instead of being paid, add-on libraries. Second, the UI components were custom designed for engineering applications including gauges, tanks, and intensity charts. As a generality, the most critical aspect of UI development in an engineering application is the simplicity of data visualization. The LabVIEW UI was designed for the concept of visualizing time-based waveform measurements, the kind of measurements most commonly associated with real-world analog data such as temperature, vibration, and voltage.


Almost 30 years later, the LabVIEW UI is still well-suited for visualizing measurement data. Over the years, engineering tools have continued to evolve, closing this gap in UI functionality and ease of use. But it was the evolution of the consumer mobile market that seriously changed user expectations. Users now not only want, but expect advanced concepts in their UIs such as gestures, resolution scaling, and dynamic movement.

Most pragmatic users of LabVIEW are entirely content with the functional display capabilities of LabVIEW today. However, they voice their opinion on the Idea Exchange, and these typically fall into three categories:


1.      General Look and Feel
The LabVIEW UI was designed to mimic the front panel of a physical instrument, graphing measurement data and providing a layout of knobs and sliders to control the measurement parameters. The design decisions made to this effect are often antiquated for the expectations of today’s modern UI principles. I often hear LabVIEW users say “this UI looks like it was built in the 80’s.”

2.     Customizability
Generally speaking, the Control Editor inside of LabVIEW helps developers apply a wide range of customizations to UI elements, breaking down each control to its elemental components where pictures, designs, and color schemes can be applied.


Blog Screenshot.png

It’s not the functionality capability that most developers want to see improved, but the simplicity in applying sophisticated customizations and extensions. LabVIEW lacks a well-structured API to interface to these customizations, instead relying on an interaction editor to accomplish the task. That lack of automation from a tool centered on the concept of automation is limiting.


3.     Portability
Lastly, the portability of LabVIEW UIs are minimal. The portability requirement is generally either to scale to a different size or resolution of monitor, or to a mobile-based device. By design, the LabVIEW UI is vector-based, which fundamentally limits the scalability or portability to different sizes or platforms.


These limitations leave LabVIEW behind where we want to be in terms of UI design, functionality, and portability. Redesigning the foundation of any UI is a difficult, multi-year effort. Fortunately, we’re significantly far into this investment-unfortunately, we’re not quite far enough. Over the next few years, you’ll begin to see our investment reach the point of deployment…deployment to you.


Follow along as we near that deployment; we’ll be sharing more information with you along the way.



Phillips headshot.jpg

Today’s Featured Author

Jeff Phillips considers LabVIEW as essential to his day as food, water, and oxygen. As senior group manager for LabVIEW product marketing at NI, Jeff focuses on how LabVIEW can meet the changing needs of users. You can follow him on Twitter at @TheLabVIEWLion.

Today’s post is part of a monthly series exploring areas of focus and innovation for NI software.


Shelley Intro Image.JPG


Whether we love them or hate them, UIs–the veneer on our code, configuration, hardware, and data analytics–define our experience and influence our productivity. GUI history is remarkable. From the unsuccessful yet influential Xerox Star in 1981, to the 1984 Macintosh and Windows 3.0, we saw multipanel windows; desktop metaphors with paper, folders, clocks, and trashcans; browser wars brought dashboards; and Windows 8 introduced live tiles. This history provides a map for what GUIs may look like in the future.

Engineering and scientific UIs were historically distinct from consumer or architectural design. For NI, GUIs are rooted in the success of virtual instrumentation, which mimicked legacy box instruments. The virtual instrumentation approach trumped traditional test and measurement software teams who lost sight of basic UI design in a frenzy to build more features.

LabWindows/CVI is an example of an engineering-specific GUI, an interface to mimic traditional box equipment.


Today, we are in a transition where UI design is more than a competitive advantage, it’s a requirement. Heavily influenced by consumer experiences, today’s users seek solutions which offer as much intuitiveness as function.

We should all demand GUIs which are:

  1. (actually) Graphical – End unintuitive TUIs (I thought I made that up but didn’t).
  2. Skinnable – Different than customizable, your UI should come with themes, skins, and documented extensibility points.
  3. Modern - This means a clean, minimalist design (more is NOT better in the UI world) to let you focus on the data and information rather than the control.
  4. Designed – Layout, color, font, and hue saturation all matter. Don’t assume these elements aren’t necessary.

To meet these demands, vendors are investing in interaction, user experience, and user interface designers (including NI). I predict we will see more UI trends such as:


  • Flat – 2013 was the year most design experts began teaching and preaching the minimalistic design approach featuring clean, open space, crisp edges, and bright colors to emphasize usability
  • Mobile design – with consideration for high-end graphics power and heat leads to simpler interfaces and two dimensionality (Metro and 2012 Gmail redesign)
  • 3D – led by gaming and content industries, direct 3D and OpenGL technologies give us a beautiful experience on powerful platforms with 3D rendering, shading, and transparency effects (AIGLX for Red Hat Fedora, Quartz Extreme for Mac OS X, and Vista's Aero)
  • Virtual Reality – growing in feasibility, heads up displays are no longer reserved for pilots, VR is showing up everywhere from the 2013 PriusAirbus Smart Factory


Regardless of future designs, the most important element to plan for: design trends will and must evolve.   Profit margins and adoption of your products will be defined by the user experience – which is first experienced through your user interface. 


Need more convincing? Forrester Research finds that “a focus on customers’ experience increases their willingness to pay by 14.4 percent, reduces their reluctance to switch brands by 15.8 percent, and boosts their likelihood to recommend your product by 16.6 percent.”


Do you agree? Tell us what you think by commenting below or connecting with the UI Interest Group to learn tips and tricks from top LabVIEW developers.


Shelley headshot.jpg


Today’s Featured Author

Shelley Gretlein is a self-proclaimed software geek and robot aficionado. As NI’s director of software marketing, you can find Shelley championing LabVIEW from keynote stages to user forums to elevator conversations. You can follow her on Twitter at @LadyLabVIEW.