5-6 years ago, an
NIWeek keynote speaker explained how the rise of broadband to the home would change the way people used the Internet. It wasn't due to the increased speed of broadband over dial-up. He said it would be due to the Internet being "always on". While it only took 60 seconds for the modem to dial, connect, and start passing data, the reduction of this time to 1 second would cause a fundamental usage change. Today, the Internet has certainly become pervasive and I can't argue with his reasoning.
I noticed the same thing when I installed my wireless LAN in my house. Besides learning that Macs were infinitely superior in the "it just works" category, it was amazing to see the difference in how I used my laptop and its networking capabilities. This was not just "cable replacement", it caused a switch in the way I used the technology. I see it every day with people bringing their laptops to meetings so they can look up information during the meeting or "hiding" in a conference room to get real work done.
These two examples both show that advancing the technology doesn't necessarily mean that you can simply "do more" along the same axis that the technology advanced. Yes, you can download bigger files over broadband, but it's causing bigger changes than just that.
So what technologies are going to change the T&M world? "Wireless sensors" is an emerging technology. Is cutting the cord and reducing wiring costs the only benefit? Or will it cause a shift more substantial? What if you could hook up to a sensor without disturbing the others who are taking that data? What happens when I can "see" the thermostat on the wall, or the car counting sensor in the concrete? Ah the possibilities.
Since it's the first day of NIWeek, here's a performance tip for everyone
The traditional LabVIEW demo is to place a random number generator feeding a chart indicator inside a while-loop and running it. The application merrily generates nice wavy lines on the graph at high speed. Clone the loops so that there are two in parallel and they update simultaneously. It shows how quickly you can make some sort of interactive application with LabVIEW. Unfortunately, we are showing a bit of bad programming style in this demo. Luckily, there's an easy way to turn that example from a "huge consumer of CPU time" to an "appropriate programming model". Convert the while-loop into a timed-loop and set the loop speed to 60Hz. There's no reason to update your UI faster than the refresh rate of your monitor. It will save a lot of CPU bandwidth for other things.
This is a trick you can use at home. Look through your code and see if you have indicator terminals inside loops. Does that indicator really need to be inside that loop? Do you really need to update the indicator more than once? Updating an indicator takes time, especially when the front panel is visible (
or even just in memory). If it doesn't need to be updated frequently, pull that indicator terminal out of the loop.
If the indicator really does need to be updated in that loop, are you waiting at all in the loop, either via the wait primitive or via the timed loop? If not, you should probably add one. Otherwise, you are going to eat a lot of CPU time doing needless work.
A few years ago, I took a look at a customer's application because it was running differently on a laptop than it did on our embedded controllers. The application had a main loop that was acquiring data and it wasn't running quickly enough. After peeking at it for 30 seconds in the LabVIEW profiler, I saw that it was spending 98 percent of its time in a subVI that wasn't even called in the loop. Huh? It turns out that the application was spawning a hidden dialog box that had no wait in it. As you may remember from my
55ms article, LabVIEW tries to balance the needs of parallel operations. This hidden dialog was eating all of the CPU time and crushing the performance of the application. Simply adding a wait primitive to that one dialog increased the data acquisition loop speed by TEN TIMES.
Check your waits
Use the profiler
So if you are an NI customer, you probably know that
NIWeek is next week. If didn't know NIWeek is next week, let me know and I will give our sales folks and PR department 50 lashes... This is your chance to come see what we've got up our sleeves and talk to the folks that designed and implemented all of these products. It was a lot of fun last year showing LabVIEW programming a Nintendo Gameboy-based robot, which was really a sneak-peak at the Embedded Development Module.
Embedded, DSP, and PDA presentations are all over NIWeek and, for those of you interested in running LabVIEW off the desktop, I encourage you to catch one or more of the following sessions:
Intro to the LabVIEW Embedded Development Module - 1:30pm Tuesday
Hands-On LaVIEW PDA Module - 2:45pm Tuesday (also 11:45am Wednesday)
Teaching with LabVIEW DSP - 4pm Tuesday
Keynote on Wednesday - you don't want to miss that one - 8:30am Wednesday
Embedded Processors and FPGAs as a Target Platform for LV Embedded - 1:30pm Wednesday
Hands On - Using LabVIEW Embedded with Blackfin Processors - 1:30pm Wednesday
Hands On - Using LabVIEW Embedded with Blackfin Processors - 10:30am Thursday
LabVIEW for Embedded Design - 11:45am Thursday
I'll be running around constantly for the next week. Maybe we should have a "meet the bloggers" night with the other
bloggers at NI. There's a good chance I'll be wandering around the expo hall Wednesday after 5pm.
Speaking of Wednesday night, if you want to see a bunch of 11-year olds outsmarting experienced engineers, check out the
RoboLab challenge. It's pretty amazing.
