Prologue
In May 2019, at what would become the last NI Week ever, I led a session called “Learning to Love Text Again With Measurement Studio.” It was scheduled for 8:30 AM on the last day of the conference, so I was surprised that so many travel-weary engineers stumbled in, red-eyed, with clumps of taco still stuck in their hair, ready to listen to me talk about what I thought was a fairly niche topic. I was wrong! The room was filled with enthusiasm, although some of it was already about where to get lunch.
It is now December 2022. NI Week is gone, but the Test & Measurement community is still hungry for Austin’s spectacular tacos and alternative software development platforms. A mere three-and-a-half years later, I have finally found time to convert that presentation into a series of blog posts for those of you who weren’t there (or who slept through it). The intent is to motivate the use of Python or Microsoft’s .NET platform as programming environments for Test & Measurement Automation, and to provide you with some guidance toward getting started.
Introduction
This post will focus on NI’s Measurement Studio, what it is, and why it’s useful. In another post, I will write about the procedural advantages (code reviews, separation of concerns, multi-developer teams) of developing Test & Measurement applications in .NET or Python. In yet another, I will write about the abundance of tools available to you in those environments (like ORM, web applications, etc.).
Motivation: Using the Right Tool for the Job
As engineers, we know that there are many ways of doing a thing, and that there are many tradeoffs that need to be considered before deciding how the thing will get done. Programming languages are a dime a dozen, and they all pretty much do the same thing. So, if you’ve already got LabVIEW competency, why invest the time in learning Microsoft’s (extremely large, complicated, and intimidating) .NET stack? On the face of it, that doesn’t seem like a worthwhile tradeoff if both languages get the thing done.
LabVIEW’s dataflow language is a great way for engineers without programming experience to write data-acquisition software quickly, without fear of encountering some freakish horror like:
/usr/lib/../lib/crt1.o: In function `_start': (.text+0x20): undefined reference to `main'
This is one reason why LabVIEW will always occupy a 32x32 pixel area of our hearts: quickly acquiring and visualizing data just doesn’t get any easier; however, as software reaches a certain level of maturity or complexity, other development environments can substantially simplify the management of the software’s lifecycle. DMC develops extremely large Test & Measurement applications with deep inheritance hierarchies and complex sets of dependencies. As a project gets larger and larger, it becomes more and more difficult to manage LabVIEW code, work on it with a team, control & assure its quality, and deploy it to customers.
Over the last several decades, the software community (separately from the engineering community) built itself many tools to achieve those same goals. As the two communities have converged over the years, their tools have become available off-the-shelf not just for the software developers, but for the mechanical engineers, the electrical engineers, and everyone else. Test & Measurement applications can stand to benefit from improved processes that already exist thanks to those tools. For example, .NET, Python, and other languages offer:
- The humble and mighty diff (an easy way to compare two versions of textual source code)
- Tools for multi-developer scenarios (for example, GitLab and GitHub — which work much better with text than with VIs)
- Tools for code quality (such as linters, formatters, and so on)
- Huge libraries of third-party packages
- Really sweet dynamic UIs
- More opportunities to adhere to good programming practices with object-oriented programming paradigms
Note: again, there will always be a time and a place for LabVIEW, but it is not “all the time” and “everywhere.”
What's the Problem, Then?
The problem is that you’re busy, and you don’t have time for this.
But what if I told you that getting started with .NET doesn’t mean you have to start from scratch? What if I told you that NI predicted this traumatic event and already provided the tools that you, a LabVIEW developer, would need to productively develop an application in C#?
Measurement Studio
A lot of people familiar with NI’s ecosystem have never used Measurement Studio and don’t really know what it is. Here’s what it is not:
- Measurement Studio is not a new language (it’s regular ol’ C#)
- Measurement Studio is not a new IDE (it’s regular ol’ Microsoft Visual Studio)
- Measurement Studio is not the same as LabWindows/CVI
- Measurement Studio is not a set of hardware drivers
What Measurement Studio is, however, is the bridge between LabVIEW and .NET. It is a set of tools that are analogous to the ones you’re used to in LabVIEW, so you can take everything you know about LabVIEW programming and easily transition it to C#.
Same Concepts, Different Angle
You already know how to acquire data from DAQmx in LabVIEW:
If you wanted to do the same thing in .NET, your code would conceptually be the same, just... rotated 90 degrees clockwise:
As you can see, NI provides a consistent API for DAQmx across multiple languages. There’s the familiar LabVIEW API for DAQmx and a parallel .NET API (i.e., there's basically a one-to-one mapping of LabVIEW VIs to class methods in C#), as shown above. For Python fans, I would also recommend NI's Python API for DAQmx, which we've also used.
Hardware Drivers are Already Available!
Any time you install the DAQmx drivers, you have the option of installing the .NET language bindings, too. The DAQmx drivers are not a part of Measurement Studio (they come with all NI hardware that supports DAQmx). The same goes for some other drivers, so DAQmx, NI-VISA, and NI-GPIB drivers all have “.NET Development Support” options in the installers — even without Measurement Studio. Some have even been open-sourced and hosted on GitHub, like the Vision Development Module for .NET! Others are available as a separate download, like .NET APIs for NI-Switch, NI-DMM, and NI-FGEN. See NI’s documentation here for more information.
Measurement Studio's Value-Add
You already have your hardware drivers available, and you already know how to use them, so whether you’re working in LabVIEW or C#, you can acquire some data. Now you need to do stuff to it. In LabVIEW, you know how to do stuff to data. You do stuff to data all day long; it’s literally your job! So, if you’re going to work productively in C#, you’ll need to know how to do the same things. This is where Measurement Studio makes your life substantially easier. Once you install Measurement Studio, you will have access to .NET libraries that provide the same functionality that you’re already using in LabVIEW, and they’re even organized in the same way:
Butterworth Filter Example
The parallels extend down to individual VIs, which typically map to a single .NET function or class. For example, consider the Butterworth Filter VI:
The analogous .NET library is provided by Measurement Studio and would be used like this in C#:
using NationalInstruments.Analysis.Dsp.Filters;
var newFilter = ButterworthLowpassFilter(order, fs, fh);
var filteredX = newFilter.FilterData(X);
You simply create a ButterworthLowpassFilter object with the same order, fs, and fh parameters that you’d wire to the VI. You then call that object’s FilterData() method on the input array (X), and it gives you the filtered output array (filteredX).
There’s a specific lowpass filter class, so you don’t need the filter type input, and the fl value isn’t applicable. Nor do you need the init/cont input (the nature of object-oriented programming means you don’t need to manipulate the filter’s state at the same time you’re trying to use it). I would make the bold claim that, while this may seem unfamiliar at first, the VI is trying to do too much, so the C# code is ultimately more intuitive & readable than the VI is!
TDMS example
Whether you’re using LabVIEW or C# to glue the parts together, you’ve acquired your data with DAQmx, filtered it with a Butterworth filter, and now you need to store that data in a TDMS file. In LabVIEW, you might have something like:
And the equivalent C# code, using libraries provided by Measurement Studio, is:
using NationalInstruments.Tdms;
var tdmsFile = new TdmsFile("C:\filePath.tdms", new TdmsFileOptions());
var channel = tdmsFile.AddChannelGroup("DataGroup").AddChannel("DataChannel", TdmsDataType.Double);
channel.AppendData<double>(123.45);
tdmsFile.Close();
Unlike hardware drivers, which already have .NET language bindings available in their installers, the data analysis and TDMS methods in C# are provided by Measurement Studio.
What I hope is evident from these examples is that you don’t need to start from scratch when you use Measurement Studio. It provides equivalent classes & functions to the VIs you already know you want. Measurement Studio is just a parallel universe where the only difference is that you develop data acquisition software with your keyboard instead of your mouse!
Debugging
The code itself is only one piece of the puzzle. The IDE is a big part of the programming experience, too. As I mentioned before, Measurement Studio is not a new language or a new IDE. The language is just standard C#, and Measurement Studio installs a few extensions to Microsoft’s Visual Studio IDE, which is an extremely powerful programming and debugging environment.
It’s easy to acquire, filter, and write your data to disk, but, as you develop your application, you’ll eventually need to debug a problem. In LabVIEW, you’ve got your trusty probes, breakpoints, and execution highlighting. What do you do in Visual Studio? Exactly the same things!
You can easily add breakpoints (yes, conditional ones, too) and step through your code line-by-line. This is standard in Visual Studio (and virtually all IDEs).
Since Measurement Studio’s .NET class libraries provide data types like the ones you’re familiar with (for example, AnalogWaveform), it also provides “data tips” so that the debugger can inspect (“probe”) those data types while you’re debugging.
Visual Studio brings some of its own fun debugging tricks, too. For example, you can:
- Edit code while it’s running in debug mode!
- Change the flow of execution (i.e., manually move to particular lines of code) while you’re debugging!
- Change the values of variables in memory while you’re debugging!
Visualization
When it comes to graphs & charts, nothing’s easier than LabVIEW. In Test & Measurement applications, you’re almost certainly going to need to plot some data, and Measurement Studio makes it easy.
The current standard for GUI development in .NET is WPF, which provides standard controls and indicators like buttons, text boxes, sliders, etc; however, as a LabVIEW developer, you’re going to want some LEDs, some touchscreen-friendly switches, and some high-visibility dial gauges alongside your graphs and charts. Measurement Studio has you covered here, too, by providing familiar controls and indicators for your WPF user interface:
And, as a bonus, WPF provides plenty of customization and styling options — as well as hardware-accelerated vector graphics and easy re-sizing.
Summary
Measurement Studio gives you the following tools to help ease your transition from LabVIEW to .NET:
- Convenient NI-style controls, indicators, and graphs that you’re used to
- Convenient NI-style data types that you’re used to
- Convenient NI-style APIs for all the analysis functions you’re used to
- A convenient NI-style TDMS API that you’re used to
These tools can help you continue to work productively as you migrate from LabVIEW to an unfamiliar programming environment. With all these convenient, NI-style tools available, you can ease right into it.
All I’ve done here is talk about how Measurement Studio can help if you choose to develop your application in .NET instead of LabVIEW. We haven’t even discussed why you would choose that! If this post has made C# seem more accessible with Measurement Studio but you're still not sure why it's worth trying, then I would suggest reading through this related post to give you more insight on how platforms like .NET and Python can help you build and maintain your Test & Measurement software.
Learn more about DMC's Test & Measurement Automation solutions, and contact us today for your next project.