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.
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.)
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.
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.
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…