I was having a discussion (sometimes called “arguing” 
) with another engineer at NI about how to maintain state in a LabVIEW application. We disagreed on the best way to maintain state in his application. Since at least two LabVIEW experts don’t agree on this topic, I think it will make a good topic for this blog. We also talked about how LabVIEW could make some things easier for what he was trying to do.
In this multi-part post, I want to start by explaining what state information is and why you might need it. Then I want to explain different ways you might want to implement it, including a comparison to how other languages support state information.
In computer science, there’s a concept of a purely “functional” subroutine, in which the subroutine returns values which are only a function of the inputs to that subroutine. Such a function has no side effects on the state of the rest of the system.
Consider the “add” function, for example…
Given the same input values for x and y, the add will always produce the same result.
A subroutine that has one or more side effects can’t be “functional”. Let’s consider the case where we want to keep a running average of acquired data points. (You might do this if you want to smooth the data to remove noise.)
Help With LabVIEW Research Project
Happy new year from the NI Field Architects! Just a quick post to let you know of an opportunity for you to make LabVIEW better.
As you might imagine with a product as powerful as LabVIEW, we are working on a variety of research projects with several leading universities around the world. There’s one in particular that I want to highlight today.
At Oregon State University, Dr. Chris Scaffidi and his students imagine a LabVIEW that guides you to write better code.
DETT Saves the Day!
Disclaimer: This is not a veiled marketing post, attempting to entice you to purchase Desktop Execution Trace Toolkit (DETT). However, we and our customers have experienced much value from this tool and we think it’s valuable for anyone writing large LabVIEW applications. (Perhaps we would should have listened to NI’s marketing presentations earlier. 
)
Are you currently using Desktop Execution Trace Toolkit (available for LabVIEW 8.6.1 or later)?
If you answered yes, skip this post, or rather fast forward to the comments and let us know if you have additional feature requests.
For those of us who are not using DETT, does anyone actually have a reasonable excuse? Cost? Time? One more tool to learn?
Costs Too Much?
NI wisely rolled DETT (as well as VI Analyzer and the Unit Test Framwork) into the LabVIEW Developer Suite in 2011. So if you own Developer Suite, you have no additional cost. Otherwise, it’s a $999 investment with an enormous payback. One customer was able to identify and fix 90% of the memory leaks in less than a day. Another was able to identify the source of unreported errors in minutes. Those undetected issues would have been far more expensive had they not been repaired prior to deployment.
Time Consuming?
Yes, this is one more step in your process. It does take time to run your code through various scenarios. However expending a few hours or a day during development may save you that or far more after deployment.
One More Tool to Learn?
Yes, but this tool is very simple and you should be up and running over your lunch break, even if you only have a spare 30 minutes. Follow these steps:
- Enable VI Server Support by going to Tools>>Options>>VI Server and selecting TCP/IP under Protocols. If you don’t, the DETT will remind you about this step. (Note that the reminder
- Once you are in DETT, select new trace.
- Specify the instance that you want to trace.
- Select Start.
- Run your code.
It’s really that simple.
But Wait… There’s More…
Packed Project Libraries – Part 2
My inbox has been filling up with emails from those of you who have been eagerly awaiting this follow-up to the previous post. Okay, so the truth is that I went on a post-NIWeek 6-week vacation and am finally back at work. [Or perhaps Nancy was doing the other part of her job... helping customers be successful through face-to-face interaction.--ed.]
In the last post, we looked at the typical use cases and benefits for Packed Project Libraries (PPLs). However, as the Field Architects have been working with customers, we ran into a few issues.
We are faced with a design challenge when working on large projects with multiple Packed Project Libraries (PPLs), specifically layers of libraries. We need to understand how PPLs link to other PPLs when a hierarchy of PPLs exist. Let’s look at an example…
Our first guest blog post… we’re excited to have a short write-up from Aristos Queue (known in real life as Stephen Mercer, one of our Senior Software Engineers in LabVIEW R&D).
A rumor has reached my ears. A false rumor about LabVIEW, inlining subVIs and buffer allocations. A rumor in need of quashing.
read more…
Do you know the party game, “telephone”? It’s where a group gets in a circle, and someone whispers a statement to the person next to them, who in turn whispers it to the person next to them, until the message gets all the way around the circle. Invariably, the message gets corrupted along the way, and the statement at the end has lost all of its original meaning. I find it both funny and sad.
The same thing seems to have happened with some information on race conditions and functional global variables in LabVIEW, so I want to try to clear it up.
It started earlier this week when I found an NI-internal document that’s used for code reviews, which said…
Functional Global Variables
A way to avoid race conditions associated with local and global variables is to use functional global variables. Functional global variables are VIs that use loops with uninitialized shift registers to hold global data.
· …
· The FGV eliminates race conditions
Whoa! Given no context, that last statement is just plain wrong.
An internal document is one thing, but I’ve also heard this echoed by at least one customer in the past month, and also in an informal conversation here at NI.
What’s going on??? I decided to find out. Keep reading to understand more about race conditions and how this game of “telephone” progressed to where we are today.
LabVIEW Robotics at NIWeek 2011
I was the original NI technical lead for the LabVIEW Robotics products, and very much enjoy the Robotics and Autonomous Vehicles Summit at NIWeek.
As usual, we had some great demonstrations, presentations, and discussions. Fresh off his victory in the Adult Size Humanoid League at RoboCup 2011 in Istanbul, Turkey, the CHARLI-L2 robot from Virginia Tech’s Robotics and Mechanisms Laboratory was a big hit with the NIWeek crowd. Here’s CHARLI with Dr. Dennis Hong. (And a plug for Dennis’ TED talks on robotics.)
Here’s Bryce Lee, one of Dennis’ graduate students. Bryce Lee is a former student of my friend, Dr. Dave Barrett, a professor at Olin College of Engineering.
And because you can never have too many Virginia Tech robots, here’s DARWIN-OP, which won the Kid Size Humanoid RoboCup 2011 League. He’s an especially charming robot. 
We had some great sessions, too. Dr. Sangbae Kim from MIT spoke about his robotic cheetah and other biomimetic robots. (Read this Wired Magazine article about Sangbae’s work.)
Dr. Harry Asada, also from MIT, spoke about his undergraduate robotics course, using LabVIEW and CompactRIO to solve the problem of plugging a miniature oil wellhead.
A graduate of Dr. Hong’s lab at Virginia Tech, Dr. Karl Muecke is one of the members of the LabVIEW Robotics R&D team. Here he is showing our updated DaNI robot.
Robots showed up in the keynotes, too. Here’s a photo from the Day 2 keynote, Shelley Gretlein (with Matt Spexarth) showing off her dancing skills in front of a LabVIEW-controlled Microsoft Kinect sensor. This powerful sensor is becoming popular in robotics. In front of Matt in this photo are also Boston Engineering’s robotic tuna fish, and Virginia Tech’s DARWIN-OP robot.
If you missed the keynotes, the NIWeek keynote videos are online.
We’ve got a lot going on with robotics at NI. The new version of LabVIEW Robotics 2011 is worth checking out. The biggest new feature is the environment simulator, which lets you test your robot in a virtual world. Because of our integration with the sensor drivers, very little code has to change when moving from the simulated world to the real one.
Finally, we can’t talk about robotics at NI without mentioning our work in K-12 education, and our efforts to promote Science, Technology, Engineering, and Math. We are proud of our collaboration with LEGO on the WeDo and Mindstorms products. And we are also proud of our collaboration with FIRST robotics.
I want to close with a story of one engineer’s impact on the world. It features Nicole Richard, one of NI’s next generation of outstanding leaders, and my friend. Nicole manages our LabVIEW K-8 product development.
Wow, what an NIWeek!!! Are you as exhausted as we are? We had some great meetings with customers and our field sales teams. A big thank you to all of you who took the time to say hello and talk about our favorite topic: LabVIEW!
There are so many highlights. So many things we saw, so many discussions, so many old and new friends, so much music to dance to. What was your favorite? If you had a favorite session, discussion, or party, post a comment about it below.
One of the highlights for me was sharing time with the LabVIEW 1.0 R&D team. I didn’t show up until LabVIEW 1.1 timeframe, which technically qualifies me as “new”. In the weeks leading up to NIWeek, Jeff Kodosky found each of the ten members of the LabVIEW 1.0 team and invited them to NIWeek 2011 for the 25th anniversary of LabVIEW.
I’ve always been inspired by this group. They took a chance on a skunkworks project working in a small campus office near The University of Texas at Austin, surviving mostly on Double Stuf Oreo cookies.
The LabVIEW 1.x “About” window had digitized photos of the team members. Here’s a photo with the team members standing in the same order as the “About” window. (Click on the images to enlarge them.)
Here’s another photo, with Dr. T sporting his LabVIEW 2.0 t-shirt.
The LabVIEW 1 team received rock star attention from the NIWeek attendees. Who knew that we had NIWeek paparazzi?
On Tuesday, I had a great informal lunch with several members of the team. It was so nice to catch up. I really enjoyed answering their questions about what NI is like now, and what the LabVIEW team is like today.
A big thank you to all ten of you… Paul, Lynda, Cathie, Lalo, Jeff K, Jeff P, Ken, Rob, Steve, and Rosy. Thanks for immortalizing your bitmap images in the software, and thanks for joining us 25 years later.
NIWeek 2011 Recommendations
NIWeek is our favorite conference of the year. Look for us next week and say hello.
As always, we strongly encourage you to attend all of the keynotes. The Wednesday keynote will be pretty special as we celebrate the 25th anniversary of LabVIEW.
Jeff Kodosky, Cofounder, Business and Technology Fellow, NI
Hear from Jeff Kodosky, the “Father of LabVIEW,” as he looks back at the creation of graphical programming and shares fundamental programming concepts vital to the next 25 years of graphical system design for meeting the most demanding application challenges.Shelley Gretlein, Director of Core Platforms – Software, NI
Shelley Gretlein, a key member of a new generation of leaders at NI, has been instrumental in the evolution of LabVIEW and empowering domain experts with graphical system design. Join Shelley in celebrating the 25th anniversary of the LabVIEW and see how engineers and scientists around the world use LabVIEW to innovate and develop pivotal world-changing applications. Learn how the global LabVIEW community will address the world’s biggest engineering challenges over the next 25 years.
Jeff has managed to find most of the original LabVIEW 1.0 developers and invited them to attend next week. (Brian is looking forward to seeing some old friends!)
Since the Field Architect focus is on software architectures and good programming skills, we wanted to highlight a few sessions that should be interesting. As always, there are many, many great sessions going on at the same time, so bring your LabVIEW friends to NIWeek, then split up and cover more sessions.
System Components With Object-Oriented Design Patterns
See how you can design and implement stand-alone, data-driven system components using applicable Gang-of-Four object-oriented design patterns and the model-view-controller composite architectural pattern. Learn why interfaces are important along with a simple way to create a basic functional equivalent in LabVIEW. Follow an example from state machine design to implementation incorporating reusable libraries.
Paul Lotz, DCT Software Engineering Manager, Lowell Observatory
Tuesday, August 2 ▶ 1:00–2:00 p.m. ▶ Room 14
Building Quality LabVIEW User Interfaces
Review the components of a good LabVIEW user interface and design techniques aimed to communicate the purpose and function of your application at a glance. This session is for developers who build applications for others or who work on code that will be handed off for future development and maintenance.
Simon Hogg, LabVIEW Product Manager, and Nitin Thomas, Staff Software Engineer, NI
Tuesday, August 2 ▶ 1:00–2:00 p.m. ▶ Room 13A/B
Beyond State Machines: Building Modular Applications in LabVIEW
Nearly every significant LabVIEW application uses multiple loops and several pieces of hardware. Coordinating these moving pieces can create a recipe for unreadable code. Learn how to use a template for interprocess communication based on “public” and “private” events that is easy enough for intermediate developers but powerful enough for Certified LabVIEW Architects.
Justin Goeres, System Integration Expert, JKI
Tuesday, August 2 ▶ 2:15–3:15 p.m. ▶ Room 14
Advanced Error Handling in LabVIEW
Examine the challenges of implementing a full-featured error handling strategy in LabVIEW and the tools to meet some of the most common error handling needs. Discuss error classification and description; central versus specific error handling; and techniques for communicating, logging, and reporting errors.
Ryan King, Systems Engineer, NI
Tuesday, August 2 ▶ 3:30–4:30 p.m. ▶ Room 14
Practical Examples of LabVIEW OOP Classes and Use Cases
Examine practical LabVIEW object-oriented programming (OOP) class definitions and their uses in real-world applications; design considerations for the class definitions; and inheritance, dynamic dispatch, and effective use of public and private methods. Examples include a family of logging classes, a general-purpose communication class, and an interprocess messaging system.
Mark Yedinak, Engineer, Zebra Technologies Corporation
Tuesday, August 2 ▶ 4:45–5:45 p.m. ▶ Room 10C
Building a Complete Data Monitoring and Storage System With CompactRIO
Building a configurable monitoring system for synchronized measurements can be challenging. Design considerations include robustness, compatibility, configurability, acquisition speed, and traceability. Examine the software design considerations for engineering such a system, and discuss advanced software techniques, design patterns, and software architectures.
Arnoud de Kuijper, Engineer, T&M Solutions B.V.
Tuesday, August 2 ▶ 4:45–5:45 p.m. ▶ Room 11A
Customizing LabVIEW Controls and Indicators
The LabVIEW control editor lets you modify how the built-in controls and indicators look. Walk through what you can do with the control editor, how to do it, and a behind-the-scenes look at how they created the new “Silver” control theme in LabVIEW 2011.
Simon Hogg, LabVIEW Product Manager, and
Christina Rogers, Senior Software Engineer, NI
Tuesday, August 2 ▶ 4:45–5:45 p.m. ▶ Room 13A/B
LAVA/OpenG Barbecue
A premiere networking event for LabVIEW experts at the historic Scholz Garten in downtown Austin. $30/person.
Register at http://lavag.org/bbq
Changing Your Mindset for LabVIEW Real-Time and LabVIEW FPGA Programming
Have you used LabVIEW for your desktop and considered using LabVIEW Real-Time or LabVIEW FPGA for your next project? Learn what to expect when making the transition and how to avoid common pitfalls.
Ryan King, Systems Engineer, NI
Wednesday, August 3 ▶ 10:30–11:30 a.m. ▶ Room 14
Team-Based Development Techniques and the Impact of Source-Only VIs
Learn configuration management best practices, including how to manage files using the LabVIEW Project Explorer, integration with popular source code control tools such as Subversion, and how the new source-only VI file format can help ensure that code changes do not cause a ripple effect through your application hierarchy.
Peter Guo and George Martinez, LabVIEW Senior Software Engineers, NI
Wednesday, August 3 ▶ 1:00–2:00 p.m. ▶ Room 14
Building Plug-In Architectures and HALs
Watch as we apply two popular software design patterns from the Gang-of-Four text to illustrate examples of powerful and scalable architectures in LabVIEW. View a command pattern as an alternative to a traditional producer-consumer pattern in demonstrating basic object-oriented concepts. This example also illustrates the use of a factory pattern to dynamically load and create plug-ins, which is used in a HAL example.
Elijah Kerry, LabVIEW Product Manager, NI
Thursday, August 4 ▶ 1:00–2:00 p.m. ▶ Room 17B
Best Practices for LabVIEW Real-Time Development
Go into your next LabVIEW Real-Time project with confidence. Gain insight from NI experts on how to improve reliability, reduce jitter, and optimize performance in your real-time systems.
Tanya Visser, Engineer, NI
Thursday, August 4 ▶ 2:15–3:15 p.m. ▶ Room 13A/B
Software Engineering Tools for LabVIEW
As LabVIEW plays a larger role in increasingly complex systems, it’s important that developers have access to software engineering tools that can help ensure application quality and reliability. Gain an overview of the LabVIEW tools that can help automate and improve some of the most time-consuming aspects of software engineering.
Elijah Kerry, LabVIEW Product Manager, NI
Wednesday, August 3 ▶ 2:15–3:15 p.m. ▶ Room 14
Thursday, August 4 ▶ 2:15–3:15 p.m. ▶ Room 14
Software Engineering With LabVIEW
Get hands-on experience with revision control, Subversion, NI Requirements Gateway, LabVIEW VI Analyzer, LabVIEW Unit Test Framework, and LabVIEW Desktop Execution Trace toolkits.
Elijah Kerry, LabVIEW Product Manager, NI
Tuesday, August 2 ▶ 2:15–3:15 p.m. ▶ Room 18C
Wednesday, August 3 ▶ 10:30–11:30 a.m. ▶ Room 18C
The LabVIEW Compiler and Memory Management Techniques
Explore the internal workings of the LabVIEW compiler and execution engine and learn how to use those principles to optimize your code for improved run-time performance and memory use.
Adam Bordelon, Staff Software Engineer, NI
Tuesday, August 2 ▶ 4:45–5:45 p.m. ▶ Room 14
Tips and Tricks to Speed LabVIEW Performance
Join an interactive presentation that covers a variety of simple techniques to improve VI performance.
Darren Nattinger, Engineer, NI
Thursday, August 4 ▶ 10:30–11:30 a.m. ▶ Room 17B
Trends in LabVIEW Object-Oriented Programming
NIWeek 2011 marks five years since object-oriented features first appeared in LabVIEW. This style of LabVIEW programming continues to show its power. Examine interesting frameworks, online resources, and good programming practices that focus on new innovations since NIWeek 2010.
Stephen Mercer, Senior Software Engineer, NI
Tuesday, August 2 ▶ 3:30–4:30 p.m. ▶ Room 13A/B
Organizing Your Company’s Test Data With the ATML Standard Using NI TestStand and DIAdem
Every department within a company wants to use its own file format for data collection, analysis, and archiving. Learn how the ATML standard can help you store truly parameterized and relational data that can be easily imported into a standard database and other applications including Microsoft Office and NI TestStand.
Christopher Relf, Chief Architect, V I Engineering Inc.
Tuesday, August 2 ▶ 4:45–5:45 p.m. ▶ Room 15
We also want to highlight a few other blog posts about NIWeek 2011 that we think you’ll find helpful…
- Sixclear’s 6 Tips for NIWeek 2011 Maximization
- Eli Kerry’s Blog Post About Advanced Software Sessions at NIWeek 2011
- JKI’s Unofficial Guide to NIWeek Fun
Welcome to LabVIEW Journal! The Field Architect team is thrilled to be working with teams of talented and creative engineers throughout the US, helping them tackle the next software challenge. With NIWeek 2011 around the corner, it seems fitting to discuss a LabVIEW 2010 feature.
We are working with one team that faces a few issues related to the deployment of updated API’s (Application Programming Interfaces, or libraries, or groups of VIs with a specific task or responsibility). This group is well organized with clear roles and responsibilities for specific libraries that are rolled into a larger test application. However, the clean handoff and distribution of updated code has been cumbersome.
Enter Packed Project Libraries (PPLs)
A packed project library is simply a compiled .lvlib that contains all of the .lvlib’s VIs and allows the user to call the public VIs in a manner that is identical to the use of the original .lvlib.
Assume that someone is tasked with writing an analysis library that will be used by a broader team. The developer places all of the code in an .lvlib (recall that an .lvlib is simply an xml file that references the VIs which actually reside on the computer’s file system). The team has jointly defined the interface to the library and as such, public VIs are provided for their use. The implementation details that may change over time remain buried in private VIs.
Create a Packed Project Library – .lvlibp
1. Ensure code is complete, reviewed, and tested. Check that VIs have proper access scope. The developer selects access scope by right clicking on the VI in the project. Public access scope allows any VI to call the .lvlib’s VI. Private access scope ensures that only VIs that are also members of the .lvlib can call the VI.
2. Create a build specification and run it. PPLs are not an ideal distribution format for libraries that will be changed or modified fairly regularly. Once compiled, the process can not be reversed. This is on par with DLLs and EXEs. The process moves in one direction. Compiled code cannot be reverse engineered into the original source. Some may consider this a drawback, others may deem it a benefit. The developer of the library can easily modify the source in the original .lvlib and subsequently recompile and redeploy.
3. Distribute the PPL to team members. What were formerly public VIs of the .lvlib, are now called Exported VIs in the .lvlibp. They are used in the calling code in the same manner as the public VIs of the former .lvlib.
4. Initially transition to the .lvlibp. You can right click on the .lvlib and select the option to replace with a Packed Project Library. This feature is included to facilitate the transition to using PPLs. No feature is included to reverse the process, see below.
Ensure Better Software Development Processes
In summary, PPLs are an elegant solution for the smooth deployment of a group of VIs from the developers of those VIs to the team who will be using the code. One .lvproj is used for PPL development and then the PPL could be utilized in unlimited projects. Those who are using the PPL cannot edit the VIs and have no exposure to the private VIs. PPLs force us to implement a few practices that we often skip: ensure code is complete, reviewed, and tested. Then deploy the code.
As noted above, once you convert calling code to use a PPL, LabVIEW does not have a native mechanism to revert the calling code such that it now points to the original .lvlib. Rumor suggests that a very enterprising Applications Engineer at National Instruments wrote code to revert back to *.lvlib. However reverting breaks the original intended use case for PPLs. As bugs and features are needed in the PPL, it is the developer’s responsibility to make changes to the .lvlib, retest, rerun the build, and distribute it to the team.
Easily Update Libraries called by a Test Application
Once the test application has been deployed as an exe, updating to a new PPL is straightforward. The build specification for Test.exe allows the developer to select the directory in which the PPL will reside. Updating to a new version requires a simple copy of the new PPL to the Test.exe’s directory, replacing the old file. As such, Test.exe is not modified thus saving the time to revalidate. Test.exe must be rerun to call the new version of the PPL.
Look Under the Hood
Let’s consider the use case in the previous paragraph. What would happen if developers where not using PPLs? Answering this question requires that we dive into the details of how the LabVIEW execution system works. One of the nuances of LabVIEW is that a change in a subVI can cause calling VIs, potentially numbering in the hundreds, to be forced to recompile. Changes that force the recompile include modifications to the inplaceness algorithm of the subVI or specific changes to the connector pane. (Brian Powell might comment on the inplaceness algorithm in a future post, provided the community vigorously asks him to do so). When PPLs are not used, the calling code would detect the changes and force the recompile.
So what is happening in the LabVIEW execution system once PPLs are in use? The execution system now recognizes that a difference exists between expected state of a PPL subVI and it’s newer state (different inplaceness etc.). So the caller is intelligent and when changes occur, it uses a VIServer-like methodology to call the subVI that is part of the PPL. As such the caller has the responsibility to do what ever is necessary, potentially copy data, etc., so that it can call the subVI in it’s newer state without the recompile. All of this is transparent to us, the users of the PPL. Without the forced recompile, many users may experience the benefit of reduced build times.
Address the Issues With Hierarchies of PPLs
We’ve covered the basics. Now we move to a more complicated situation that we encountered. Let us consider the use case in which LibaryA.lvlibp calls LibraryB.lvlibp. When LibraryA is first compiled to a PPL it will place LibararyB.lvlibp in a support directory. This is fine, until Test.exe will call both LibraryA.lvlibp and directly call LibraryB.lvlibp. Building Test.exe requires that a new copy of LibraryB.lvlibp be placed in a support directory, thus two copies now exist. Fully describing this scenario and the potential solutions will be detailed in a future post. However, it did convince us that PPLs are not yet perfected.
Talk About Your Experiences
As Brian noted in his post, we are utilizing this forum for an honest conversation about our challenges and the best solutions moving forward. We look forward to your comments, commendations, and criticisms about Packed Project Libraries. Your ideas and feedback will help drive improvements to this and other features.