In the past, we have showed you how to use the Actor Framework to create highly modular and easily scalable applications in LabVIEW.
In this article, I’d like to share a few tips that have helped me when working with another popular framework in NI’s product line-up: TestStand.
As LabVIEW developers, we are comfortable developing in LabVIEW. However, sometimes we need to leverage code from other languages. This is where DLLs come in. For those of us that are less than comfortable with coding languages outside of LabVIEW, using DLLs can be daunting and frustrating. The Import Shared Library Wizard can make your life easier, however, it is not very reliable when using custom data types. This forces us to use Call Library Function nodes (CLNs) for DLL calls, which can bring up a whole bunch of problems with no intuitive debug strategy.
If you attended my presentation at NI Developer Day back in March, you probably recognize the content of this three-part blog series. The premise of my presentation was simple and rather obvious given its title “You Already Know How to Use LabVIEW Classes.” In the end, object-oriented LabVIEW is simply a programming style that encourages software modularity and reuse. The doing is easy because it requires mostly bits and pieces with which we are already familiar.
The Bloomy BTS team is excited to be travelling to Novi, MI next week for the 2016 Battery Show.
NIWeek 2016 was a great success for Bloomy and for the Bloomy BTS team. From touching down in Austin Sunday morning through our Thursday departure, we had an extraordinary 5 days of connecting to partners, customers, vendors, and friends. Thank you to everyone who helped make this arguably the best NIWeek yet. There is much to recap, so we'll start with our top 5 listing from July and go from there.
NIWeek 2016 kicks off Monday August 1st with the Exhibition Hall doors opening at 5:30PM. Bloomy’s BTS (Battery Test and Simulation) team has been hard at work preparing for what looks to be the most exciting NIWeek for us yet! If you plan to be at the show, here are 5 exciting things to look out for, and of course please be sure to come by our booth (Booth #205) to say hello. For those who won’t be at the show, I’ll be posting a conference summary soon after we return, with relevant links to the highlights and to materials that will have been presented.
In my previous post, I introduced the concept of object-oriented inheritance. I also suggested that, as a regular G developer, you already know enough to start writing your own object-oriented code.
Maintaining this same (I hope empowering) perspective, let’s dive into the next foundational principle of object-oriented programming: encapsulation. Look for a post covering the final principle (polymorphism) shortly.
Bloomy’s Battery Test and Simulation (BTS) team continues its participation at industry conferences in 2016, following a successful presence at the ESA (Energy Storage Association) 26th Annual Conference this past April in Charlotte, NC. At the event, Peter Blume spoke on "ESS Performance Testing for US DOE Energy Storage Smart Grid Demonstration Program". To view the presentation, see ESS Performance Testing - ESA 2016.
You Already Know Enough to Get Started
If you do not currently leverage object-oriented programming techniques in your LabVIEW code (believe it or not) you likely know more than enough to get started. Object-oriented programming is not magic—it is a programming style built for modularity, and maintainability. As a regular G developer, you probably encounter clusters, libraries, type definitions, property nodes, and polymorphic VIs on a daily basis.
Are you developing test sequences using NI TestStand? If so, beware that a lot more goes into a full test architecture than test sequences. In our experiences, test developers often focus solely on the test sequences and code modules, leaving items like file management, hardware abstraction, operator interfaces, and result processing all but forgotten until you run into a problem. Unfortunately, these items often take longer to develop, and require more in-depth TestStand knowledge than the test sequences themselves.
