Community Browser
Showing results for 
Search instead for 
Did you mean: 

[Point of VIEW] Yo Ho, the Timing’s Right for Me


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

Active Participant


Stephen B

Brittany, thanks for posting this heads up.  I agree that anything to increase a users productivity in LV is a good thing as long as we can still do the low level stuff under the hood.

Are these new features being planned for LV2015 or 2016 ?

Peter Badcock
Product Development
ResMed Ltd.

I would like to hear that you work on improvements for LabVIEW as a general programming language.


@sletrab Hear, hear! Quick access to acquiring data is probably good per se, but how about giving us tools to write modern programs with modern user interfaces? When will you guys add formal support for Unicode? Native support for localization? Modern UI controls? No offense, but as a personal preference, I take pains NOT to install SignalExpress and DataFinder.


Ditto what Sergey said!

Member HLB

LabVIEW has become somewhat dispersed with independent features.  All "improvements" to LabVIEW should stem from and be directly accessable through CODE.  DIAdem is not that way.  Dynamic Data Type is not that way.  The CODE is central to LabVIEW.  The CODE is the backbone to LabVIEW.  The TOOL aspect of LabVIEW is very necessary to assist the development of CODE in LabVIEW.

Active Participant


We are steadfastly dedicated to ensuring that LabVIEW has the ability to add significant value to key business issues that you're facing today. With the last few releases, we did this not through a significant amount of new LabVIEW features, but rather by ensuring the integration of DataFinder technology into LabVIEW applications. With the growing trends of Big Data and the Internet of Things, simplified access to data to drive business decisions is a quickly evolving need. Many of these enhancements will help our users expand the reach of their applications from simply getting the data to providing recommendations based off of it.

As the velocity of new features has slowed, I also want to ensure you are aware of the improvements in the product's stability and performance (run-time, edit-time, and load-time). We have a team of our best architects (internally called “LabVIEW without Limits) that focus on these technically deep issues. In LabVIEW 2014, we saw a 9x performance improvement for the loading of large applications and some very significant run-time performance improvements for some key RF algorithms.

With all of that said, it's important to understand we are still investing heavily in the LabVIEW product - in fact, we are investing more resources in the software platform in the 2015 development than ever in our history. The size of the platform, number of new hardware devices, and the scale of improvements that we're making limit our technical ability to do "phased roll-outs" in the product. As such, these improvements will be "bigger/more fundamental" as the rumor mill has implied. However, we aren't quite there yet. This blog forum is intended to provide a more open dialog about these investment arcs that we're making as a company.

Jeffrey P.
LabVIEW Product Management
National Instruments
Active Participant

I'd like to make a fundamental distinction between "LabVIEW" and the programming language. LabVIEW is a software tool that we have designed and optimized specifically for engineers and scientists looking to interfae with the real-world through data. Fundamental to this tool is G, the graphical programmming langaged defined by the semantics of dataflow.

G is a fundamental technology that we invest in, in conjunction with investment into the LabVIEW environment that surrounds the G language. Many of the investments that we're making are based in G and many are based in the LabVIEW environment.

I highly encourage you to read some of the previous posts. I used the "point_of_view" tag to pull out just these posts in this series. You'll see some discussions of environment improvements and elements where we're making G easier to approach for novice users. As we continue to move forward, we'll get into more topics that are centered around G as a language.

Jeffrey P.
LabVIEW Product Management
National Instruments