Paris, France – We’re in the midst of the 2013 European CLA Summit. We have over 50 CLAs meeting for two and a half days, discussing advanced LabVIEW concepts. This year’s theme is Interprocess Communications. We’ve had presentations by several CLAs from around the world. (Including a few CLAs who traveled from the USA to attend.)
The CLA Summits are like a very intense LabVIEW User Group Meeting. We are having lots of great discussion, generating lots of new ideas, and we’ve met several new friends. A big thanks to NI France for hosting us.
Here’s a photo of Jeff Kodosky giving opening remarks at the Summit.
We’ve had tremendous growth at the CLA Summits—record attendance in both Austin (over 100 CLAs) and in Paris. Keep working on your LabVIEW CLA certification, so we can see you at next year’s summits.
We’re big fans of the LabVIEW Desktop Execution Trace Toolkit (DETT). Nancy wrote an article about it that helped drive some new features for 2013. Thanks to those of you who provided input.
Here are some of the new features…
- Updated user interface, including a “ribbon” interface and fixes for the mouse-wheel
- Improvements for continuous monitoring applications and for selecting which data to capture. The old DETT would collect data until it ran out of memory. Now, you can log to a file or discard data to make room for new data.
- Improved searching for text in the traces
- The ability to compare traces
The new DETT supports LabVIEW 2010 and later; you do not have to upgrade to the latest LabVIEW. Note, however, that the new DETT will automatically uninstall your current DETT. If you want to downgrade, you will need to uninstall the beta and install the old version. Also note that you can load your old trace files into the new DETT.
Sign up at the Beta Program Resource Center. Your application will be reviewed and you will be informed by email once you’re approved. We would like to have all of your feedback by May 15, 2013.
Thanks to all of you who showed up for our NIWeek session about code reviews with LabVIEW. We’ll have a longer posting soon, but I wanted to make a few downloads available for you right away…
If you have any questions about these, please comment.
NIWeek 2012 Recommended Sessions
That terrified look on our faces is the realization that NIWeek is only a few days away. Ready or not, here we come!!!
There are soooo many great sessions. If you’re not coming to NIWeek, you’re missing the year’s best event for learning about LabVIEW. Come prepared to take a bunch of notes, network with a bunch of really smart people, and learn about a bunch of new technology.
First, let’s talk about the important stuff…
In my last post, I showed one of the big downsides of using preallocated clones—when you have a large hierarchy of preallocated reentrant VIs, the number of clones in memory can get big fast.
In this post, I want to clarify one thing about reentrant hierarchies, and then start talking about how to work our way out of these programming problems.
Let’s summarize where we are so far…
In part 1, we started talking about VIs that maintain state information from one call to the next. I want to clarify that there are two different kinds of such VIs. Sometimes you want global state—no matter where the VI is called anywhere in an application, you want its state to be shared among calls. This is what a functional global variable is. FGVs are, in general, not reentrant, to protect against parallel access to the global data. In part 1, I introduced a different flavor, where you don’t really want to share data across all calls; you wanted each call to have its own state, but you wanted each instance to maintain state between calls.
In part 2, we learned why VIs like this have to use preallocated clones, not shared clones. But what are the downsides of always using preallocated clones? What does “reduces memory usage” mean?
In part 2 of this series, I showed how shared clones can’t be used for VIs that maintain internal state. I want to explain a few more details about how shared clones work by answering a few common questions…
- When are shared clones allocated? How many are allocated?
- When are shared clones deallocated?
- How do shared clones behave inside timed loops?
- How do shared clones work with the VI Server?
In the first part of this discussion, I ended with homework that asked questions about shared clones and whether they would work for the running average I was trying to compute per channel. I included a graph showing that the filters worked correctly when set to use shared clones.
As answered in the comments, using shared clones is wrong in this case. But why was the graph right?
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.