Ideas in Wiring

Engineering our future

2008-06-18T12:49:00.000-07:00

As engineers and scientists, we're trying to make the world a better place. In addition to our day jobs, there are things we can do off-hours too. If you can take two hours a week from whatever else you are doing and instead continue to be an engineer, I have a suggestion for you. Please be a mentor. You can be the inspiration to an entire classroom of elementary school students to become engineers and scientists when they grow up. In addition, you get a chance to be a kid and even play with toys - engineering toys.

One way is to be a mentor for a FIRST Lego League (FLL) team. Every fall, teams of 4-10 elementary and middle school students get a big box of LEGO pieces and a challenge. By December, they need to have built a fully autonomous robot that will complete as many challenges as possible as well as a presentation on the challenge topic. This year, over 2000 teams participated in regional, national, and international competitions culminating in the FIRST World Festival in Atlanta, Georgia. It's fun to watch how the kids grow through their participation. The shy learn to speak up, the dominant learn to share, and they all get to experience some fun that they may not normally get in their school day.

(image taken from usfirst.org website - yes, the trophy is made of LEGO pieces)

If you want to work with high-schoolers, FIRST also has two other competitions: FIRST Tech Challenge and FIRST Robotics Competition. While the FLL robots are small and plastic, the FTC and FRC robots get heavier and more powerful. FTC robots are around 24" cubes that weigh 5 pounds and the FRC robots get up to 120 pounds and the size of a refrigerator.

(image from usfirst.org website)

40% of FRC participants end up going to engineering school in college. At the FRC finals in Atlanta, I saw 20 colleges with information booths. Athletes aren't the only way to get scholarships now - some schools are giving them out to FRC participants.

Inspire an engineer - get involved. You won't regret it.

Some days you just have to shake your head

2007-10-04T08:28:00.001-07:00

The Power.org organization just met in Austin and one of their conversations was on multi-core programming. Some days, I just feel sorry for programmers stuck in the traditional embedded world. This is from an EE-times article:

"The inability of C/C++ code to parallelize coupled with its ubiquity throughout the embedded market is a major issue for multi-core going forward," Heikkila wrote in a follow up email to EE Times. "Any alternative parallel programming languages certainly won't materialize in the embedded market, but instead will more likely gain momentum in a more mainstream computing market before making its way into embedded applications," he added.

And more bad news for current developers

So far, engineers are giving embedded software a low grade of just 2.06 out of five in terms of its readiness for multi-core.

One day, they'll use LabVIEW....

Profiling Multi-Core Applications

2007-07-31T14:18:00.000-07:00

A while ago, I wrote an article about writing parallel programs. The next question is: how do you optimize them?

Note: if you are writing multi-core programs and are coming to NIWeek, please email me (email address on the right). I'd like to talk to you about this topic further. But I digress...

Typically, when optimizing an application, you are trying to make it faster. "Faster" usually means "reduce the time the user observes the task to take". We sometimes call that "wall clock time". Occasionally, there is no outside observer. Instead, you want your task to be less of a disruption on other applications. In that case, you are purely concerned with how much of the resources of the computer, typically the CPU, are being consumed. This consumption could be called "CPU time".

When optimizing for wall clock time, you quickly run into some difficulties.

1) Most profilers give you time of operation in CPU time. A function that goes to sleep for 10 minutes has a CPU time of nearly nothing but a wall clock time of 10 minutes.

For example, if you run this VI with the LabVIEW profiler enabled, it will show that it uses a whopping 46.9 milliseconds

So, you think. Wow, my application took 10 seconds and this function only took 47 milliseconds, I guess my slowdown is elsewhere. And, of course, you would be wrong. Now, this example is pretty silly. No one just adds a sleep for the heck of it. Normally, you'll find "sleep time" in a couple of different places

Pausing because you need to synchronize with other event. Maybe you go to sleep for 1 second until some external piece of hardware has responded.
Calls into the OS. Reading from disk and writing from disk occurs in the OS. The CPU time returned by the profiler doesn't normally show time spent in the OS, even though it is consuming CPU cycles.
Calls into a driver. Some driver calls do their work inside the OS so they are a case of #2. Or, sometimes they get implemented as a LabVIEW sleep, and so they also don't get counted.
Task swaps. The OS might decide to give some other application some time. This hurts the wall clock time of your application but your profiler won't tell you.

If you want wall to measure wall clock time, you should instead get the tick count of the machine before and after the operation occurs. A tick count uses wall clock time to give you the results. My profiling article shows you how to get the tick count to profile an operation.

2) Things get a bit weirder when you want to try and optimize on a multi-core computer. On a single core machine, you can make your program run faster by either reducing wait time like you saw in #1 or by reducing the CPU time. On a multi core machine, a task can have a shorter wall clock time even though the CPU time and wait time are the same. If you split the CPU work (i.e. CPU time) evenly across two processors, your wall clock time goes down by a factor of 2 but your CPU time is the same.

You can observe this with the Windows task manager. If you have two cores, the task manager will show two graphs of CPU utilization, one for each CPU. You can also use the windows application "perfmon" which gives you a bit more flexible way to observe this.

(the CPU Usage History shows 2 graphs, one for each processor)

So, to optimize your application, the trick is to max out both processors. In effect, you are trying to INCREASE the CPU time for the second processor by shifting the processing from CPU 1 to CPU2. It's odd to think of optimizing as increasing processor time, but that's what you are doing.

The problem with using this approach is that increasing the CPU time on the second processor doesn't necessarily reduce wall clock time. Your efforts to make your application more parallel might add CPU work, such as forcing memory copies, that negate the benefit of parallelism.

As an example, the old LabVIEW queue primitives used to copy data into and out of the queues. If you put a big array in a queue, it would spend a lot of time copying the array into the queue and then a lot of time copying it out. To make my application more parallel, I split it into loops and used queues to pass the data between the loops. My CPU utilization was great, 100% on both cores, but my wall clock time was slower because it spent a long time simply copying data around. Fortunately, we learned from that experience and the primitives don't make copies of arrays & clusters any more.

Unfortunately, there's not a really good way to look at this effect right now. Use tick counts to measure your wall clock time and use the profiler to establish a baseline. Then, as you are making changes, make sure the wall clock time is going down and the CPU time is remaining at least constant or only going up slightly.

Physics of a Radar System

2007-07-28T19:49:00.001-07:00

If you ever wanted to know how a military radar transmission works, there's a pretty good overview that you can find in this Tektronix Application Note on pages 2-6 It talks about what a radar pulse looks like and why you might modulate the pulse in order to get better performance.

They skipped the most basic type of radar system but Mattel has utilized it to make a really neat and cheap radar gun.

You can use RADAR (technically it's an acronym so it should be capitalized) to tell a number of things about object it's aimed at. The Mattel radar gun gives you the most basic information, speed. It transmits a microwave signal and observes the reflections (if any) that come back from the object. If the object is moving toward or away from the gun, the reflected signal will have a Doppler shift. The amount of frequency shift is proportional to the speed.

Now if you remember your music theory, when you mix two waves of slightly different frequencies together, you get a signal with both frequencies as well as a "beat". The frequency of the beat is the frequency difference between the signals.

Taking advantage of this, the Mattel gun combines the signal it sends and the signal it receives to get the resultant signal, filters out the microwave signals and is left with the beat signal. Get the frequency of the beat signal and it's some simple math to get the velocity of the object.

All this for $30 retail.

Now, notice that the gun doesn't give you position. Radar systems figure out how far the target is away by measuring how long it takes for the signal to reach the target and come back. To do this, they send a pulse and wait for the return and then time the return. The Mattel gun sends a continuous signal rather than a pulse so it has no way of measuring time of flight. That processing would probably also cost a bit more to implement.

Why did I even bother to read this article? Well, I'm seeing some of our customers testing radar systems by simulating return pulses with hardware such as the R-series plug in boards or our Vector Signal Generators and wanted to know a little more about what they were really doing.

Streaming Processing

2007-07-23T19:46:00.001-07:00

A device such as a digital oscilloscope uses a high speed a/d converter to acquire the desired signal for some very short duration of time at a very high sampling rate, this acquired data is then transferred through a signal processing engine that may perform some sort of analysis on the data at that point such as an RMS calculation, and then the data is transferred to the main display engine for more math (such as calculating a cursor value) and finally displayed on the screen. So the flow is simple, acquire the data, analyze it to make the measurement, and present the result to the user. For 20 years, NI has used the phrase "acquire, analyze, present" to describe virtual instrumentation. A virtual instrumentation system allowed you to create that oscilloscope yourself out of a PC, a digitizer, and LabVIEW and allowed you to write your own measurement.

However, the phrase "acquire, analyze, present" may misleadingly imply that the phases are discrete when in fact they can be continuous. Why might this be continuous? One example is the processing to perform a trigger. If a scope is going to trigger when the signal exceeds a voltage level, acquisition and analysis must run continuously to digitize the signal and perform some very simple math (comparison) to look for the threshold to be met.

As with all engineering problems, the devil is taking the simple concept and applying it to a need that our customers have. Creating that trigger is subject to two fundamental limitations: the speed at which the trigger criteria can be evaluated and the rate at which the data can be sent from the a/d unit to the trigger computation circuitry. Triggering is typically a hardware operation because it needs to run at a megasample or gigasample rate and it is performed "close" to the a/d converter to handle the data rate of hundreds of megabytes or multiple gigabytes per second being generated.

The march of technology provides some interesting opportunities on the horizon that have been alluded to in past posts. The architecture of a software defined radio (SDR) and an oscilloscope are not that different. The FPGA technology and wideband A/D technology driving SDR is beneficial in T&M applications. The biggest difference is the audience. Whereas the SDR design team consists of C and VHDL programmers working for 12 months on a highly specified design in a high process development environment, the T&M system design team is a few people who know LabVIEW trying to keep up with the changing specs being thrown over the wall and trying to avoid the end product being late even when the design team is late.

The next generation of test equipment will be leveraging the technological power available in the SDR architecture but the ease of use you expect from a T&M instrument to get those difficult measurements made. Imagine the possibilities:

Write your own math computation for that trigger, compile it, and have it run at the full rate of the hardware.
Perform calculations on the data at full speed. Need a hundred kilohertz RMS calculation to decode a LVDT? You've got it. Filter or demodulate a 20 MHz communication signal? No problem.
Take that test that you wrote but have part of it run on an FPGA to speed it up. When that's not good enough, take the whole thing and move it down to the FPGA.

All of these tasks are possible today but some aren't as easy as they could be. The technology is there to accomplish the task, the trick is to expose that power to you. NIWeek is coming up in just over two weeks. I look forward to discussing the possibilities with you there.

University of Maryland's PRAM Computer

2007-06-28T19:12:00.000-07:00

In breathless language, the University of Maryland announced "New Era of "Desktop Supercomputing" Made Possible
with Parallel Processing Power on a Single Chip". If you read the article, you will find no hint of substance whatsoever about why this is so revolutionary and that's a shame because they might actually have something.

The presentation they made at the Symposium on Parallelism in Algorithms and Architectures is similarly light on detail except for one term I was unfamiliar with so I googled it, a "PRAM Machine". This machine appears to be a simple (but ill-documented) concept

(From Wellesley CS331 Notes)
A PRAM uses p identical processors ... and [is] able to perform the usual computation of [a typical processor] that is equipped
with a finite amount of local memory. The processors communicate through some shared global memory to which all are connected. The shared memory contains a finite number of memory cells. There is a global clock that sets the pace of the machine executon. In one time-unit period each processor can perform, if so wishes, any or all of the following three
steps:
1. Read from a memory location, global or local;
2. Execute a single RAM operation, and
3. Write to a memory location, global or local.

So really, the only difference between it and a multicore Pentium is that there are probably more than 4 CPUs and that all of the CPUs share a global clock. Interesting but I think the better question is - why did they build it?

It looks like there's a whole set of theory that goes into how to extract parallelism out of algorithms and a PRAM execution model allows the task to be expressed simply.

For example, suppose you wanted to increment the contents of every element of an array by 1. This type of machine would simply have every processor load one element, increment it, and store it back. If you had the same number of processors as array elements, that operation would take place in exactly one time unit. Perfect parallelization. That particular operation is also found in "SIMD" machines. Again, the importance is not that a PRAM can implement this operation, it's because there have been languages developed that allow all of this business of scheduling all of the instructions across processors to be abstracted from the programmer.

Interestingly, it looks like we could use these same concepts to schedule LabVIEW code without having to change the diagram at all. Hmm.

Reasons for personal source code control

2007-06-19T15:18:00.001-07:00

In Jim Kring's top 5 bad excuses for not using source code control post, someone commented

Perhaps another top five is needed - “reasons a single LabVIEW developer should use scc software” - then we could decide for ourselves how our manual methods stack up.

So here's my top 5

1. It forces you to document what you changed

Each time I check in/commit a set of VIs, the SCC program (+ LabVIEW if I enable it) asks me to describe my changes. It's invaluable to have a running history of the changes you made to your code, both what you said you changed and what VIs actually were different. Here's an example from one of my personal projects

#1 - "Initial version"
#2 - "Fixed link to Open URL in Browser. It isn't in vi.lib so the paths get all messed up as soon as you move this llb somewhere else"
#3 - "Changed name of LLB and help directory. Added quoting to the URL sent to OpenURL"
#4 - "Added flashing of dots on refresh. Enhanced the help slightly. Will add to the help in the next changelist"
#5 - "Added examples and 2 more pictures to the docs"
#6 - "Completed help and examples - pre final review"

That code was written in November 2001 and by looking at that brief history, it takes me back through what I was doing.

2. It tracks code in multiple areas with ease

Code that spans multiple folder hierarchies on disk can be a problem for the "make a copy as a backup" technique. Good source code management systems can track code spread across your disk. Did you put code in user.lib and in your documents & settings area? No problem. As soon as you have code in more than one directory, I question how meticulous you will be about copying "everything". Instead, you'll start getting lazy which takes us to #3.

3. You can always revert to a good (or at least known) state

If something goes horribly wrong, I do a "save" rather than "save as..." and nuke a VI, I can always recover to something known. It can be accomplished in 3 mouse clicks rather than searching around on the hard drive. For SCM systems that are "changelist" based (such as CVS, Subversion, and Perforce), you can pull from a particular known good state. "Give me what I submitted on 5/21/2007" and you know those VIs actually work together. That's why one of the "good scm practices" is to put EVERYTHING that could change under SCM.

4. You can get everything back 6 months from now

This is another version of #2 & #3. Suppose your nifty user.lib extension changes 4 months from now. Can you rebuild your nice little utility that used an older version? Do you even have that older version of the extension any more? Keep everything that could change under SCM, including the OpenG tools that you get from Jim and you can always roll your environment back to the way it was 6 months ago and have a clean rebuild. We put our C++ compiler under SCM here at NI so if we need to rebuild LabVIEW 8.0.1 for some reason, we can make sure we are using the exact same build environment as when we first built it.

5. Allows you to track your components

You got those nifty OpenG tools and you (gasp) modified a VI! How do you keep track of those changes? What happens when they upgrade those components? How do you make sure you go re-modify the source with your changes? Manual record-keeping is not your friend here.

6. More disk efficient

Maybe in this age of big hard drives, this isn't an issue. But how many times are you going to make a duplicate of a 30 meg folder hierarchy because you changed one VI. Do you stop and say "maybe not, I'll do it later". That goes through my head.

Hear me on a TechOnline roundtable with respected experts

2007-06-13T10:16:00.001-07:00

Embedded systems are getting more complicated and harder to program. What can be done about it? You can come hear a panel of experts (+ me) talk about the challenges of embedded systems programming and a risk of programmer shortage in the future.

The round table participants are all current or former editors of Embedded Systems Design magazine and are folks I've read for a long time. I've been reading Jack Ganssle's column since 1994 when I was at Motorola Semiconductor and Dan Saks's articles when I was still programming in C++ on LabVIEW so it's neat to share the virtual stage with them.

This web-cast came about because the current editor in chief of Embedded Systems Design magazine, Rich Nash, wrote an article postulating that there was an emerging coding crisis. It generated more letters to the editor than anything else he had done. You can see them in the online comments to the article as well as a follow up reader response article.

So, if you're not going to be busy on June 19th, please sign up and listen in. There will be a Q&A section at the end if you want to ask follow-ups or you can post questions to me here if you want.

There are some trends I'm especially interested in discussing such as high level programming tool adoption, difficulties programming multicore processors, and how FPGAs might change things.

Code Reviews

2007-05-10T08:32:00.000-07:00

A recent post on Embedded.com about Peer Code Reviews got me thinking about the process we use in the LabVIEW team for checking in code. It came about many many years ago and is, in my opinion, the most effective process I've seen. We call it "buddying", but a lightweight peer code review is probably the technical term.

It can be summarized quickly as: No code gets checked into the main branch unless the changes have been reviewed by a second person.

The practical process is
1) The programmer makes the code changes. These changes may be checked in to a private branch in source control or may be just sitting on his/her hard drive.
2) If the changes are in the 100-line or fewer area (which is a majority of submissions), the programmer goes and "gets a buddy". The buddy is typically a senior level programmer who is already familiar with that code area but that's not a hard rule.
3) The author walks through each line of the changes with the buddy and explains the changes. The buddy points out any stylistic problems, double checks for off-by-zero or null pointer handling code, and reminds the author about any gotchas that may be in that area.
4) If the buddy is satisfied with the code, it gets checked in to the source code control system and the author & buddy's names are noted.

That's it. It adds about 10 minutes to each code submission and keeps a lot of "doh!" errors out of the code. If you don't have a system like this now, I recommend you try it. We find it invaluable.

Manipulating Data Files

2007-04-26T11:15:00.000-07:00

Jim Kring posted techniques in his blog future-proofing data files by adding schema and version information to the file. Over the years, we’ve added some file formats to LabVIEW that make it hard for customers to follow his rules and that can cause problems.

I’ve seen folks hang themselves with the Datalog file by writing a file with one particular type definition (i.e. cluster) and then can’t read the file any more when they change clusters without understanding it will affect backward compatibility.

The newer file formats in LabVIEW like .TDM datalog files are much more maintainable because they store the type definition (typically called a ’schema’) in the data file so you can’t lose it and so it can be browsed by an external application.

Technorati tags: LabVIEW, DataStorage

Writing Stylish Code

2007-04-25T11:42:00.000-07:00

Working on a codebase that is authored by a lot of people has given me a new appreciation for writing consistently styled code. Even having 10 programmers all writing in a different way makes it hard to go in and modify or fix code written by someone else. In the C/C++ community, there are constant wars about indention or variable naming. In the end, it's not really important which convention you pick, it's more important that you pick one and stick to it.

LabVIEW is no different and it may be a bit more difficult because we give you 2 dimensions (X and Y) in which to place your code rather than just one. I just saw an announcement for a new LabVIEW book and thought I'd pass it along.

The LabVIEW Style Book - Peter A Blume

Best-Practice Style Rules and Standards for Developing Quality LabVIEW Software
Drawing on the experiences of a world-class LabVIEW development organization, The LabVIEW Style Book is the definitive guide to best practices in LabVIEW development.
Leading LabVIEW development manager Peter A. Blume presents practical guidelines or "rules" for optimizing every facet of your applications: ease of use, efficiency, readability, simplicity, performance, maintainability, and robustness. Blume explains each style rule thoroughly, presenting realistic examples and illustrations. He even presents "nonconforming" examples that show what not to do-and why not.

I like that he mentions a tool that we release and use internally for our own G code reviews

Code reviews: Enforcing a style convention using a checklist, the LabVIEW VI Analyzer Toolkit, and peer reviews

Check it out.

Technorati tags: LabVIEW, CodingStyle

Tracing Software During Hardware Test

2007-02-15T09:00:00.000-08:00

In my last post, I mentioned a need to find software faults in microprocessor-controlled embedded systems. Since I'm a software guy, I'm curious about this angle and started doing some reasearch.

1) The faults that were mentioned (timing, memory leaks, crashes) are basically software domain problems but they may only be triggered by certain I/O inputs the system receives (and the sw ends up dealing with). So, it looks like the main tools to diagnose the fault will need to be ones that deal with the software domain but the system may need to be driven from the hardware I/O domain.

2) These challenges are similar to those found in other applications that use microprocessor-driven control systems. For example, NI makes hardware that can be used for real-time process control (such as controlling valves in a paper mill). The controllers need to run 24x7, just like a radio, and the entire system is controlled by the microprocessor. NI needs to make those controllers robust and therefore we need to test them extensively.

3) The automotive industry also uses microprocessor-based high speed control systems, especially to control the "powertrain" (engine & transmission). They use a technique called Hardware in the loop testing. The real controller (ECM) that is to be mounted in the car is hooked to a "simulator". The ECM sends out real output signals using a real wiring harness to the simulator, the simulator then looks at the outputs from the ECM and calculates what the real engine would do and then sends signals back to the ECM that make it think it is talking to a real engine. You then "drive" the ECM as if you were driving the car through various scenarios and the simulator checks to make sure all of the outputs from the ECM are valid. At the same time as the simulator is running, they monitor the software running on the ECM to verify that it is operating properly. If the ECM crashes, they have tools to tell them what happened in the software. It would seem like you could do exactly the same thing with software defined radio test.

4) In the auto industry, they typically don't have an OS and they do the tracing at a low level. In the old days, this was done with a chip emulator. The emulator (or logic analyzer) would snoop the address and data bus to monitor execution. Now that caches are so prevalent, the external bus is not a good place to monitor. Chips that Freescale makes for automotive such as the MPC565 have a port called NEXUS. This port works in conjunction with information coming out on the address/data bus to spit out information while the processor is running that gives visibility into the processor pipeline. You can tell that a branch was taken, not taken, etc.. even if the instruction stream is all in the cache. There are boxes such as the Lauterbach ICD Trace that hook up to the chip for this purpose. Their tools can then show the full execution history, what led up to the processor crash, etc. WindRiver, GreenHills, and other emulator vendors also have this capability.

It would seem like this concept could be applied to Software Defined Radio. A Radio Emulator could drive the radio under test while the radio is being monitored with a tool like this. In the automotive case, I don't know how much this trace data ends up getting synchronized to the operation of the HIL emulator. It might be critical to share control or timing information between the radio emulator and the trace tool so that you can correlate the waveform signals precisely to the line of code being executed. This is where I think LabVIEW would come in. HIL simulators provided by NI partners use LabVIEW as their base and are open to be modified by the end user. LabVIEW has the ability to work with other software tools via ActiveX and other interfaces. It should be relatively easy to get LabVIEW to control both the HIL simulator and the trace tool.

5) Since SDRs typically run high function OSes like GreenHills Integrity or WindRiver VxWorks, there are some additional tools that would be useful during debug. WindRiver has a tool called MemScope that will monitor the heap so you can see memory leaks. LabVIEW could control this tool also. GreenHills has a leak checker but I haven't had any luck finding out more details on what it does.

I'm looking into setting up this type of system in our lab. We have a reliability lab here for testing our real time controllers and we're looking at adding a tool like MemScope (since we use VxWorks in our controllers) to our testing arsenal. We may add on a trace tool as the next step after that.

Testing Software Radios

2007-02-06T13:27:00.000-08:00

In my visit to the SDR Forum Test Workshop, I observed something interesting. The presentations given by instrumentation vendors focused on verifying the analog and digital performance of the RF subsystem. These vendors all have very nice equipment, such as spectrum analyzers, to do this testing.

However, some of the questions from the audience during the round-table discussion asked about issues that had nothing to do with the RF subsystem. Those questions were about frustrations in testing the software in a software-based electronic system. One question was on how to get a PC to talk to the radio over the Ethernet interface. JTRS radios are typically controlled via SNMP and a user was looking for a toolkit (I found one here) to talk to their radio.

Two other attendees needed to trace a device failure to a software condition such as a stack overflow or a priority inversion, both software bugs that expose themselves as if they are hardware failures. The worst part about these bugs is that they are typically hard to reproduce and can take a long time to track down. This makes them expensive to track down because in test, time is money.

What's A Software Defined Radio?

2007-01-17T16:27:00.000-08:00

RF Test is one of the largest areas of the test market. Somewhere around 1/3rd of all test equipment purchases are for RF test. I've been looking into this market for the past 6 months or so to see we need to be doing in LabVIEW (Desktop, RT, Embedded, FPGA) to better serve people testing RF with the NI platform.

One interesting area of RF development is in "Software Defined Radio". The term is most specifically applied to the JTRS (Joint Tactical Radio System) program in the military but really applies to the way in which radio design is changing. Historically, radios were implemented in "hardware": either in chips from various silicon vendors or in discrete components on a board. You may have bought a science kit when you were 10 to make an AM radio that consisted of a transistor or vacuum tube and some other electronic components.

The design of radios is changing. The first migration was moving the signal manipulations that used to take place in the analog domain to the digital domain. A DSL modem has chips inside that use digital signal processing to convert the analog signal that travels down the copper wire into bits that become Ethernet packets.

The second migration was to perform these signal processing operations in a re-programmable device. When the 33.6 KBit modems came out, they were implemented using "standard" digital signal processors from Motorola Semiconductor (now Freescale), Rockwell, or others. Using a reprogrammable processor allowed the device to support multiple standards or to be upgradeable when new versions of the standard were released. Now, you are seeing the same thing happen with more 'exotic' radios that broadcast in the RF range rather than just ones that transmit over phone lines. The JTRS program envisions a radio that can run more than 30 different standards with the same hardware. These radios use a combination of processors and FPGAs to perform the signal processing needed to pull this off. There is still some very complex analog circuitry in the radio to pull this all off but, as some attendees of a conference I just went to noted, "the bits are getting much closer to the antenna".

Technorati Tags: SoftwareDefinedRadio, Modem, Test, JTRS

Asynchronous versus Synchronous Nodes

2006-09-05T16:16:00.000-07:00

Earlier this year, I wrote an entry about how LabVIEW's data-flow execution semantics works. There's an additional aspect of parallelism in LabVIEW that I didn't talk about: synchronous versus asynchronous nodes. A LabVIEW diagram that has parallelism in it can still appear to run in parallel on a single processor machine. The 55ms ping-pong was an example of that. Here's another example:

The top loop will run and update the indicator with the value of the loop counter while waiting for 100ms, and then repeat. The bottom loop will run and update the indicator with the value of the loop counter while waiting for 50ms, and then repeat.

The LabVIEW diagram used cooperative multithreading. LabVIEW itself didn't go to "sleep" when the top loop tried to wait for 100ms.

Instead, LabVIEW would execute the top wait for 100ms by setting a timer to go off in 100ms. Then, it would look for other parts of the diagram that could still run (like the bottom loop) and run it until that 100ms timer alarmed. When the timer went off, LabVIEW would take control back and finish executing the top diagram. The wait node was called "asynchronous" because it would let the execution system continue even though an operation (the wait) wasn't finished yet.

Well, operating systems have grown up and now we can spawn "threads". Rather than having the LabVIEW execution system use just one thread, we could allow it to use multiple threads. So when LabVIEW tried to execute a node that did block the execution system (we call those, "synchronous"), there might be another OS thread available to get work done.

You may see this when you call some C code that uses the "sleep()" call. The DLL doesn't return so the current thread is blocked but the CPU should be free to do other things. Since LabVIEW has other threads available to it, it will keep executing in the other threads.

So why continue to have asynchronous nodes at all? If you put 500 wait nodes on the diagram, we would in theory have to allocate 500 threads. Operating systems don't like that very much so we don't do that. Instead, we keep the old cooperative multitasking system but augment it by having each diagram use 4 threads. This gives LabVIEW the ability to work with external code that blocks and still have efficient execution for primtives LabVIEW knows about.

Why talk about all of this? Because sometimes we expose this to you and ask you to pick. The VISA read and VISA write nodes expose a property that let you decide whether they are synchronous or not. We even wrote an appnote on it. But, you can't read the appnote without understanding the stuff above, otherwise you'll think that asynchronous means that the node itself will return early. It won't. The setting only affects how LabVIEW internally chooses to execute the node. So why would you pick? In the words of one of our very experienced LabVIEW developers:

Frequently, VISA is used for serial I/O. If you know the instrument has data ready (e.g., you just asked for the number of bytes waiting to be read), a synchronous read will be much faster, since it won't use LabVIEW's execution scheduling mechanisms to poll the I/O.

There you have it.

Dr. T's Identity Management Method

2006-08-22T12:42:00.000-07:00

I've never seen it written down before, but this article from Joel on Software, "The Identity Management Method" really captures what it means to work at NI.

Joel says:

To be an Identity Method manager, you have to summon all the social skills you have to make your employees identify with the goals of the organization, so that they are highly motivated, then you need to give them the information they need to steer in the right direction.

Those of you who came to NIWeek probably heard Dr. T's keynote. Every year, he lays out for our customers where he thinks NI is going. Well, he doesn't just do that at the keynote. He does that pretty much every day. No matter who he's talking to and no matter what the audience, he explains his vision. Sometimes, its the very technical roadmap of the future and sometimes it's the more personal view of the various stakeholders in NI (the employees, our suppliers, our shareholders, our customers). "Sharing the vision" is an important part of our culture. It's nice to see a third party validation of it.

Well I said I wanted feedback...

2006-08-18T10:59:00.000-07:00

So now I know what it's like to be a musician, having to see a review of one of your performances broadcast widely for the whole city/state/world to see. I got mentioned in a Design News article about podcasts.

The first podcast, titled “What is Embedded?” was produced by National Instruments. It featured an interview with Joel Sumner of the LabVIEW Embedded Group. Overall I think the 16:58 minute interview fulfilled its promise, but I found my attention straying at times. Conversely, I found Sumner giving short shrift to some of the more potentially interesting topics.

The title of the post was even worse: "Listen to This Boring Podcast". Ouch. The other podcast she reviewed in the article (from another company) also got panned so at least I'm not alone.

Oh well, that was the first one I had ever done and it was part of the first 4 NI had ever done. I guess I/we have a bit of learning to do before we're the NPR of the T&M podcast world.

So, give it to me straight guys, did it suck? Too long? Right level of detail? Wrong level of detail? We've got a tremendous amount of knowledge locked up in these walls and we're willing to share, we just don't want to put you to sleep.

Technorati Tags: Podcast

NIWeek Recap

2006-08-17T06:55:00.000-07:00

NIWeek is over. Ok, it ended a whole week ago but I haven't made it to the end of my "to do list" so it won't really be over for another week or two. Last year, my team's big project, LV Embedded, launched to great fanfare. This year, another project that I was involved with, the Lego NXT, made it's NIWeek splash. I can't tell you how cool it is to see something you worked on sitting on the shelves of Best Buy or Frys.

You can see a picture of some of the main developers of the software at Dick Swan's blog. He's also got pictures of some custom sensors he's created or run across for the NXT such as a video camera, a Sony Playstation controller, and probes from Vernier. You can see the Lego NXT demo in the keynote videos.

Brian Tyler did a video-blog on the whole NIWeek Experience. I think the most amusing video was an interview with Diya on what it's like to be up on stage in front of 3,000 people doing the keynote. I love the way we throw engineers who actually worked on the products they are demoing up there. It also helps if the demo doesn't quite go as planned...

You have to admit, a DAQ board isn't much of a visual treat. It just sits there like a rock. Not even blinking lights. I think that's caused us to be a bit more creative when it comes to demos. One of the demos this year involved getting a volunteer from the audience to try out a version of the game "Dance Dance Revolution" that had been completely reimplemented in NI hardware and reprogrammed in LabVIEW. The designer of the demo is Roger Dickey, a guy who loves DDR and is in the LabVIEW FPGA team. Here's the video of him competing with the, ahem, victim.

Finally, to all of the people I pestered at NIWeek, I wanted to say thanks. I know all of us at NI get a lot of satisfaction hearing how our products affect what you do every day.

Technorati Tags: LabVIEW, NIWeek, DanceDanceRevolution, Mindstorms, LEGO

Traditions and Testing

2006-08-17T06:30:00.000-07:00

On the LabVIEW team, we love sweet stuff. Heck, all programmers probably do. "The official food of the LabVIEW team" (tm) used to be Oreos but somewhere in the last few years, it became donuts - specifically Krispie Kreme donuts. Every anniversary, birthday, or just for the heck of it yields a "donuts in (some location)" email. A sugar fix is nearly guaranteed every morning.

Another tradition is to do a coding challenge as we enter final testing. LabVIEW is pretty stable at that point and we've gone through the entire testing database a few times. A coding challenge is a good way to make sure everyone is using the product in a "real way" rather than running through some script. We let a developer or group of developers write something, anything they want, in LabVIEW. There are awards given for the program that uses the most new features, coolest, most annoying, etc.. I think I won most annoying a few years ago for using the "new" (at the time) Datasocket feature along with the state machine editor to create a distributed music playing program. Every person who loaded the VI could enter some musical notes which would then be played on every other person's machine. Can you say noisy? "Annoying" was an apt title for that one.

Anyway, my favorite entry was from the LabVIEW 8.0 release. A couple folks got together and wrote a client-server application that would not only notify you of any new donuts but also show a map on the floor of where they were sitting and map a route through the cubes to show you the shortest way to get to the donuts. It had a nice installer and ran in the system tray. Of course it was all programmed in LabVIEW.

So, what are you going to build with LabVIEW 8.2?

NIWeek Sessions

2006-08-01T11:10:00.000-07:00

There are a lot of good NIWeek sessions on LabVIEW Embedded technology. Here's my cheat-sheet

LabVIEW Embedded Birds of a Feather Session - Tuesday 1pm Mezzanine 7 - hosted by me and the LV Embedded engineering team - NOTE - this is not in the conference program
Hands-On: NI LabVIEW Embedded Module for ADI Blackfin Processors - Tuesday 2:15pm, 4:45pm and Wednesday at 1pm
Introduction to the LabVIEW Embedded Development Module - Tuesday 2:15pm
Graphical Design for Multicore Processors - Tuesday 4pm
Design of the New Handy Board for Robotics - Tuesday 4:45pm
Develop Embedded Systems without Embedded Expertise - Wednesday 3:30pm
Prototype to Custom Deployment in Hours - Wednesday 4pm
Developing Optimized LabVIEW Embedded Applications - Thursday 10:30am
Developing LabVIEW Embedded Applications - Thursday 10:30am

I hope to run into some of you at those sessions.

LabVIEW Embedded Chips

2006-08-01T11:09:00.000-07:00

The LabVIEW Embedded Development Module continues to win awards. A demo with the LabVIEW running on a Freescale ColdFire processor at the Freescale Technology Forum won "Best In Class Development Tools" by a panel of 4 industry folks. Wow.

So that brings me to some interesting trivia. I made a list of the various places that the LabVIEW EDM has run on (that I know about). Some are silly, some are amazing, but I find all of it cool

A Linksys WRT54G Router (Broadcom MIPS/Linux) - my first little project. It did everything, build, run, debug and even TCP/IP I/O. I got it to control a GPIB-Enet box and a scope.
Intel IXP425 Eval Board (Intel XScale 425/VxWorks) - one of the shipping examples
Axiom CMD565 (Freescale PowerPC 565/eCos) - one of the shipping examples
Axiom CMD565 (Freescale PowerPC 565/VxWorks) - one of the shipping examples
Axiom CMD566 (PowerPC 566/VxWorks) - This board has Ethernet so we use it for training
Xilinx ML403 Eval Board - (PowerPC/VxWorks) - This was demoed at NIWeek last year. It uses the PowerPC hard core inside a Xilinx Virtex II Pro.
Embedded Planet EP405 board - (PowerPC405/Linux) - This was in the embedded planet booth at NIWeek last year
Freescale HC08 Eval Board (HC08/no os) - One of our engineers did a power window controller for a car door. He integrated the Freescale ProcessorExpert for I/O and had it all working in a couple k of code (2k?). It didn't debug, do any arrays, or anything fancy but it was neat to see how small we could go.
Freescale HC12 Eval Board (HC12/no os) - Look for this at NIWeek this year. Get some M&Ms in the process
Altera NIOS II Dev Kit - (NIOS/eCos) - NIOS is a soft processor that runs in an Altera FPGA
Phytec LPC229x (ARM7/eCos) - A new example target
TI DSK6713 (TI TMS320C6713/DSP BIOS) - A university professor tried it first but we went and did it again as a new example target for those of you who want to program a DSP
Nintendo Gameboy (Linux) - this was the robot from Charmed Labs that you saw on stage at NIWeek two years ago.
PC Motherboard (80486/QNX) - your standard PC, but running the QNX operating system. It even can support an M-series DAQ card. Look for it in an NIWeek presentation.
A Linksys WRT54G Router (Broadcom MIPS/Linux) - my first little project. It did everything, build, run, debug and even TCP/IP I/O. I got it to control a GPIB-Enet box and a scope.
Intel IXP425 Eval Board (Intel XScale 425/VxWorks) - one of the shipping examples
Axiom CMD565 (Freescale PowerPC 565/eCos) - one of the shipping examples
Axiom CMD565 (Freescale PowerPC 565/VxWorks) - one of the shipping examples
Axiom CMD566 (PowerPC 566/VxWorks) - This board has Ethernet so we use it for training
EP405 (PowerPC405/MontaVista Linux) - Same board as before but running MontaVista Hard Hat Linux rather than the non-deterministic standard Linux distro.
PC Motherboard (80486/MontaVista Linux) - Once you have Linux running, LV Embedded works pretty well on any CPU.
Freescale MCF523x (Coldfire/no os) - A customer wanted to give this a try
Freescale MCF5329 Eval Board (ColdFire 5329/uCLinux) - The winning demo at Freescale Technology Forum.
Freescale 5200LITE (PowerPC/Linux) - A customer had one of these kicking around to try.
Renesas SH7751 (SH4/QNX) - another experiment with our friends at QNX
Atmel ATMega 128/no os - Details are sketchy but an academic customer put this together and is writing a paper on it.
The Bluetechnix tinyboard, the HandyBoard, Scmidt Engineering Z-Brain, and the ADI EZ Kits using the LabVIEW Embedded Blackfin module.

Whew. I'll bet there are others kicking around that I forgot or I don't yet know about. The breadth is fantastic, from 8-bit to 32-bit. From no-os to Linux.

Doings

2006-08-01T10:23:00.000-07:00

I know I've been a bad blogger and left you hanging for the last three weeks. It's only two weeks in work time due to a week long vacation in Prague in the Czech Republic. Prague is a beautiful city that was not bombed during World War II. You see interesting adornments on the building wherever you go. Everything is cheap by European standards. It was easily half the price of a vacation in London.

But I digress.. Last week was the Design Automation Conference. That conference is for people who make computer chips, the kind that take 10 weeks to bake in the fab before you get them back. It's a completely different world where they have to simulate everything up front because there is no possibility of even doing a component level prototype in the real world. Imagine it costing you a million dollars to fix a bug that you found in your code after your first build. That's the world they live in. However, it is an analog world at the bottom of it and LabVIEW does provide ways to help validate those designs, both in the simulation world and once the chip comes out.

NIWeek is coming

2006-07-11T11:03:00.000-07:00

In four weeks, NIWeek will be here. A post on the LAVA blogs has some good ideas on how to get the best out of NIWeek.

If you spot me at NIWeek, stop by and say hi. I'd love to chat about Embedded, FPGA, PDA, DSP, and other LabVIEW stuff (assuming I'm not already late to something). If you want to play "where's Joel", I'm publishing my NIWeek Calendar. Drop me an email if you want to chat and I'll try and set something up as my schedule firms.

See you there

Mourning the passing of LabVIEW Technical Resource

2006-07-10T13:45:00.000-07:00

This isn't particularly timely but I wanted to belatedly express my gratitude to Karen Pape from the "LabVIEW Technical Resource" magazine. They closed their doors last year and their site no longer works. It was a great, no advertisements, periodical jam-packed with LabVIEW techniques from experienced LabVIEW developers. If you ever run across a copy laying on someone's desk, pick it up. You'll probably learn something.

You can still find some of the articles floating around the Internet.
* NI's site has some articles. Go to DeveloperZone and search for "labview technical resource"
* There is a CD for sale with 9 years of articles
* Many articles have been mirrored on the sites of their representative authors

Language Challenges for Multi-Core Processors

2006-06-13T15:26:00.000-07:00

In Jim Turley's recent Silicon Insider, he talked about multi-core processors.

But new compilers and debuggers won't be enough. We're facing a change to new programming languages. Current languages like C don't express parallelism well. Compilers can identify threads of execution or independent constructs and extract some small amounts of parallelism here and there, but the language itself prevents large-scale parallelism. If we're to exploit these new multi-processor chips, we're going to have to swallow hard, roll up our sleeves, and tackle a truly Herculean task.

Hmm. Languages that express parallelism well. I wonder where I can find one of those?

Technorati Tags: Parallelism , Multicore

Do you get to talk? Do we really listen?

2006-06-09T12:24:00.000-07:00

These days, my title is "Senior Product Strategist". I work in engineering and sit with all of the developers but I don't write code any more (ah, the good old days). My focus is on figuring out what we should do next. Did any of you ever watch the original first version of the TV show "Connections"? It was all about how innovation isn't a continuous linear stream. It usually happens when someone who works in one field hears about something being done in a completely unrelated field, puts 2 and 2 together, and comes up with the next big thing in their field. I'd like to be able to do the same but I'll take just coming up with some interesting ideas.

My goal is to get to talk to you (and I mean "you" in the massively plural sense) and find out what you do, how you use our stuff now, and what would allow you to do things you can't do now. I can see the tagline now: "At NI, we make the impossible a little bit easier".

There are various things we do to try and figure out what we should be working on. We do visits, call people on the phone, send out web surveys, read comments made by seminar attendees, have meetings at NIWeek, show early concepts of what we are looking to do, read the NI Forums, Info-LabVIEW, and your LabVIEW blogs.

So here's a question: If I were sitting next to you right now, what would you want to talk about? Would you talk about things that you don't talk about now? Or would it just be stuff you already have told us in any of the places mentioned above?

My job is to listen, how can I best get you to talk? Comment below or email me at joel.sumner (AT) ni.com

Embedded Podcast

2006-05-30T14:49:00.000-07:00

We're of course a bunch of techies at NI and we love monitoring what's going on in the world. Hopefully these blogs share some of our interests. We have a beautiful audio room that's used for training and we've gone and made some podcasts on current technology. As of today, you can listen to essays on:

Safety and Isolation

What is Embedded?

A PCI Express Architecture Overview

Microsoft Vista Overview

LabVIEW Architecture

Check em out.

Personal or Project Scheduling

2006-05-16T20:18:00.000-07:00

I spent 8 years somehow managing software projects and it took years to discover a few secrets that made life easier. When it comes down to it, the job of a project manager is:

Insure that the (task/product/thing) is delivered on time with the proper level of features and quality
Insure that there is appropriate and correct communication between the team and others

That's it. The rest is just details. My best advice for a project manager is...

Do as little work as possible to accomplish those goals

After all, no one ships a project plan or a schedule. If the product ships correctly, you've accomplished your goal. Never get carried away with your own importance.

Some projects actually run themselves. You can do zero work and the project will meet the goals. But, there are cases when you need to do more than nothing.

You have inexperienced or new employees on your team
Your product depends on other products/components in development
Your schedule is dictated by other products (i.e. something else is shipping at the same time and they won't wait for you)
Other products depend upon your product and so a slip in your project will slip them also
You have remote developers
Features get inserted into your schedule midstream
Each time your team crosses a size threshold (10, 50, and 100 developers) you need to change the way your team operates.
The release date of your project has a large monetary affect
Your developers are working on multiple projects at once
Your product must be high quality (high expectations, life critical, is infrastructure other people depend on, etc..)

Many projects have these risk factors. So, you think "I need a tool to help me do this". You look up "Project Management Software" in Google and you get.... Microsoft Project. Let's talk a little about tools for second.

Project management tools are never the magic bullet they are advertised to be. They won't pull in a late project. They don't give you "the answer". They lie to you. They only work in conjunction with your brain.

They will, however, help you make sense of chaos and they will give you something to blame if you screw up. But I think the first is the only one that is valid.

So, what is the role of your brain here?

Rule #1 - Never trust a precise date.

If someone tells me a product will ship "March 25, 2004". I call BS immediately. No one can pinpoint a ship date down to the day unless that day happens to be tomorrow, and then I'm still suspicious. If you said "March", "First Quarter", or "Sometime in 2004" you would not only be more accurate but you also tell me something important: your level of certainty in the date and that tells me a lot.

So, the number one reason I dislike MS Project is that it only gives you dates with daily (or hourly) precision. It won't tell you "sometime in March" and thus it is lying to you. It's the lie of omission. The lie that makes you overconfident. I'd much prefer MS Project to tell me "I have no idea when your project will ship". That's really good information because it forces you to use your brain and go find out.

Rule #2 - Greater detail does not give you greater accuracy.

I learned this one the hard way. The schedules I created (in MS Project) for the first two years of my career constantly slipped. I went to training classes looking for the answer. I used to think they were off because I wasn't including enough details. After all, the schedule kept slipping because new tasks kept getting inserted. If I got more detailed, I'd know all of the tasks and my schedules would be more accurate. This happens to be 100% wrong because, at least with software development, you can never know ALL of the tasks. The best you can do is sketch it out and fill in the details later.

Instead, use the law of large numbers to help your accuracy. (The more things you aggregate, the greater your accuracy). I have no idea how long it will take to fix a particular bug. Could be a day, could be a week. However, you may learn from the past patterns of the team that each developer can fix, on average 2 bugs per day. So, if you have 60 bugs and 3 developers, it will probably take 10 work days to fix all of the remaining bugs. You are making an estimate but it will, in my experience, be very accurate. It also saves 60 entries in your project management software.

Rule #3 - Know the difference between unknown duration of known work and unknown work

Most software development projects are late because there's more work to actually be done or more stumbling blocks than you realize at the start. It's not that a particular task took longer to complete than you thought. It's because there was a bunch of other tasks that you never thought of or came up in the middle.

How do you deal with this? First, never make a schedule until you have scoped the work. This is not just because you need something to write down. Scoping the work forces the people involved to actually start figuring out what they need to make and that will force them to figure out how they are going to get it done. Now you have the "known work". I can't overstate how important this is. Upfront work now saves rework or mistakes or schedule slips later. I've seen it and I believe it. You can't have an accurate schedule before you know what you are doing.

The second piece of advice is the rule of 50%. It's my rule and it's based purely on experience. It may vary between projects, styles or whatever but I've found that even for a well specified project, there's about 50% more tasks there than you think there really are. This is the "unknown work". If I hear that there are 20 days worth of known work left, I can bet that they will be done in 30 days (20 days + 50% of 20 days = 30). If there are 6 months of known work left, they will ship in 9 months. And this isn't just a fudge factor. When doing scheduling, I count down the amount of work left, add 50% to it and that becomes my best guess at a ship date. In the past 4 projects, that date has been the closest thing to right. Since it's a percentage rather than an absolute, it stays accurate even as the amount of work decreases (and unfortunately MS Project can't seem to deal with that)

Rule #4 - No news is rarely good news

You can't adjust to problems unless you know about them. Engineers rarely volunteer that there are problems. They are problem solvers and so they try and fix the problem themselves. If you don't ask, they won't tell. Ask.

Rule #5 - Nothing is ever 90% (“almost”) done

This rule comes from a senior manager at NI. Progammers love to tell you that they are "almost" done. Internally translate that to "I'm almost feature complete.. That whole bug fixing, testing, integration thing doesn't count toward done.". So that means at best they are 50% done.

Making an Accurate Software Schedule

I didn't answer how to make a schedule because once you follow these rules, you're pretty much home. Use whatever you want. I use Excel. SW projects are not usually dependency driven. There is a list of tasks, you estimate a particular amount of time for each task, add in the conversion factor for meetings and other overhead (i.e. usually double the task estimate), account for unknown work (the rule of 50%), add it all up and you get a general target date. Don't tell anyone that date because it is wrong (see Rule #1). Give them the date +/- a quarter and you're probably being accurate. Update the task list weekly. Now focus on the harder things :-)

Giving Good Presentations

2006-05-08T09:57:00.000-07:00

Whenever you are in someone's office and you see a stack of magazines, don't hesitate to look at the covers and see if you like the headlines. Call it "desk surfing" rather than "web surfing".

I stumbled across an article called "Presentation Lessons from Comedians" in the an older issue of IEEE Computer magazine. It had a lot of good advice that I think can help people be better presenters. Granted, some people just have "it", that personality feature that allows them to be captivating speakers. Some people don't have "it". But, if you follow some of this advice, you will be less likely to put the audience to sleep even if you don't have "it".

Have a purpose. Decide what you want to tell them before you make a single Powerpoint slide. Make sure what you want to tell them is only 2-3 things. If you can't summarize what you want to tell them in 2-3 sentences, you're trying to do to much. Most of your talk is purely about supporting those 2-3 things.

From the article

"...if you get your story right, the delivery will follow.... [When] the story isn't clear, the audience has to work too hard to make sense of it, and they will resist it, become irritated, and finally lose confidence in the presenter. Conversely, once the story is clear, the audience will come along for the ride even if the presenter [isn't a gifted orator]."

Beat them over the head with your purpose. Don't put up a lot of data and expect them to infer what you want them to leave with.

Leave a lot out. There's plenty of neat tidbits of information floating around in the world. Leave it out. Some of your audience will care, most will find the first 3 amusing and then get bored.

Be brief. The worst sin in speaking is to go long.

Know your audience. Know what they are expecting to get out of the talk. If they are expecting you to talk about something else, they will fixate on waiting for a particular piece of information and not focus on what you are trying to tell them

Never read your slides - not only can the audience read them while sitting there, they will feel like they should just leave and instead get the slides later (which they can read in 5 minutes rather than the hour you are making them sit there). Talk "about" each slide instead.

The article had one I'd never seen before - Look people in the eyes. Don't focus over their heads, look straight at them. As engineers, I know we hate to make eye contact while speaking but this one has merit and I'll give it a try. The article states that you will get a much better read on the audience this way and it will force you to subliminally do things that actually improve your talk.

The final one I'll leave you with is

Know your material. If you know the information, you'll relax. The worst talks I've given have been NITS presentations because someone else made the slides and I didn't know the material like the back of my hand. Please never ask me to give an Advanced DAQ talk again :-)

Technorati Tags: Speaking Presentations Engineering

Danger of preserving conventions

2006-04-20T19:42:00.000-07:00

Code can be written in many different ways. There are snippets of LabVIEW code that I can look at and know the original author. The way they write their comments, the way they name their variables, and other telltale signs. I say the original author because the person who first writes the code tends to lay down the template for how the code is modified in the future. Mismatching styles in the same file cause complete chaos. You can't have three methods of error checking in the same function or else the code becomes indecipherable and hard to maintain. Therefore, modifications to the code tend to be written to match the original style, even if they are made by a different person.

This preservation can be a problem over time. There may be a technique that is better than the style being used but, since you don't want to mix the styles, you may need to change everything over to the new style rather than just a snippet. That takes work.

Sometimes, the operating environment changes out from under you and the old style is actually incompatible with the new operating environment. Recently, someone found a bug in LabVIEW that I thought was amusing. In the older Unix systems, after you call some system calls you read a variable called "errno" to see if the call succeeded. Windows followed the same convention but you called a function, GetLastError(), instead of reading a global. As developers, we try and keep the style the same so that style got reused in one of our libraries. It had a GetError() function. Wellllll.... errno isn't thread safe unless you do some special things. Our library didn't do these special things and therefore it wasn't thread safe either. When that library started getting called from multiple threads, bad things happened.

What's the lesson here? Following style is good, blindly following style is not. Question authority!

My breadcrumbs

2006-04-20T18:53:00.000-07:00

My wife and I watch people. We'll be at a restaurant and try and figure out the relationship of other patrons. Are the people at that table married? No, they look too interested in each other. Maybe they are on a first date? My wife is much better at it than I am. She always picks up the clues that I miss.

So it makes me wonder exactly what folks who see my web breadcrumbs in the righthand column think. An article about FPGA programming, one about networking technology, an ARM core for a dollar, and one on global warming. I guess my wife would have a field day with this. She'd call me a geek.

Performance Impact of Property Nodes

2006-03-29T21:25:00.000-08:00

This topic came as a result of a customer question at a NITS session. NITS is our travelling version of NIWeek. We take the best presentations on the road to a variety of cities to get our technical information out to an even wider audience. We even send our development engineers out to give the presentations because we feel like having direct customer contact is the best way for the people implementing the features to understand what people need. Someone asked what the performance impact was of using property nodes to set values on controls. I thought I'd share my version of the answer here.

The typical way of setting the value of a LabVIEW control or indicator is to pass data via a data-flow wire to the terminal. Since this is the typical case, we do the most to optimize the performance of this case. When you write to a terminal and the front panel is open, the data gets copied to a temporary holding spot called the transfer buffer. After some interval (around 60 Hz), the UI steals some time from the running program and updates the controls by copying the data from any changed transfer buffers to the control and then redraws the changed controls. So, to summarize

If the front panel is in memory (which can happen for a number of reasons - including running a VI that has been edited or upgraded to a new version without being saved)

Every time the terminal node or local variable executes, data gets copied once. The diagram immediately continues after the data copy.
Around 60 Hz, the control updates if the data changed

A property node for a control or indicator has a property called "Value". It would seem to be the same, right? Not exactly, someone on one of the forums noted that its actually 600 times slower in their test. Why? Because property nodes use a different mechanism and are accomplishing a different thing. Property nodes are typically used to set other options on the control, such as its color or formatting. So when you use a property node, here's what happens

The front panel will always be forced in memory if there is a property node to it on any diagram (thus slowing down other normal indicator updates as noted above)

The execution of the property node forces the block diagram to pause while LabVIEW wakes up the front panel. (i.e. switches threads to the UI thread)

The front panel then does whatever operation was asked (such as changing the value of the control)

The front panel then forces a redraw of the affected part of the screen (typically if the data changed but sometimes always)

Then LabVIEW switches back to the block diagram and continues

So, you get two thread swaps and a screen redraw every time you update the "value" of the control. 600x slowdown is not at all surprising when you know how things actually work

There are a couple of optimizations that you can do here

Don't use the value property unless you have no other alternative

If you are doing more than 1 property update or are doing some sort of looping, take the VI that is doing the updating and set its execution system to "UI Thread". That will move the thread swaps to the boundary of the VI rather than having them happen on each property node call

Look into the "DeferPanelUpdates" property.

Technorati Tags: LabVIEW, Performance, Programming

Site improvements

2006-03-23T15:41:00.000-08:00

Back when I was six, I had newfangled handheld computers games that adults couldn't figure out. Between the ages of 12 and 16, it seemed no adult could stop a VCR from flashing "12:00". In the blogging world, I feel like my creaky grandfather. Someone says "Web 2.0" and I say "what?"

Anyway, there are some new little widgets that you might find useful

In the top right, there's a list of articles I've read recently that you might enjoy. They are updated semi-automagically as I surf so they should stay current. You might find the articles interesting. Hopefully it's more useful information that what I'm playing on my iPod.

There is now a way to get email whenever I post something for those of you who aren't much for my irregular schedule or don't use an RSS reader.

For those of you who do use a reader, I'd greatly appreciate it if you change over to my new feed. Feedburner gives me statistics on who's reading my blog. The more people I know are reading it, the more incentive I have to write more (is there anybody out there... out there... out there... echo... echo...)

It's likely you are an embedded programmer

2006-03-23T11:12:00.000-08:00

Many of you write code on a desktop computer that is supposed to run on a desktop computer. It may be in LabVIEW, in C, C++, VB, Java, or some other language. That makes you a desktop programmer, right? Well, not so fast. The term "Embedded" is so nebulous that sometimes the definition is "anything that's not a desktop". Wikipedia has a decent definition for embedded. It says

An embedded system is a computer-controlled system. The core of any embedded system is a microprocessor, programmed to perform a few tasks (often just one task). This is to be compared to other computer systems with general purpose hardware and externally loaded software.

The key to being an embedded system is not the hardware it runs on, it's all in the software. Embedded systems have a particular task and they perform that task and nothing else. A Dell PC might be capable of being a desktop computer, but if you put software on it that turns it into something that does a particular task and only that task, it has then become an embedded system.

NI makes products that get used in a lot of embeded systems. Our customers take our products and turn them into, say, a Formula One brake test system, or a centrifuge control system. The brake test system uses an industrial PC with a Pentium 4 processor, but the application on that PC is designed to performa a particular function. It has a display that shows what the system is doing, and the operator only interacts with that system. The operator would never stick a "Quake" CD into the drive and start playing a game.

But embedded systems programming is hard, right? Yes and no. It's all about scale. If your embedded application can run on a desktop PC, then embedded programming is rather easy. Get yourself some good tools (which could even be free), take advantage of all of the thousands of programmer-years that go into Windows or Linux, and you're set. There are different form-factors for PCs, such as rugged chassis like PXI, that allow use in much more harsh environments than you would ever put something you bought from CompUSA.

The trick of embedded programming comes when you can't use PC hardware anymore. That laptop of yours doesn't fit in the pocket very well and weights a ton. The key-fob for unlocking you car has only 4 specially marked buttons rather than 101. But it's all a matter of scale. The more you optimize your hardware to match your application, the more pain you go through. But it doesn't change the type of application you are creating. You're still an "embedded programmer".

Technorati Tags
Embedded Programming, Dell, gcc

How does data flow execution work?

2006-03-03T12:15:00.000-08:00

The term "data-flow" encompasses a lot of different types of execution. You might hear about "synchronous dataflow", or "process networks". LabVIEW uses "structured dataflow". Each node on a LabVIEW diagram has a set of inputs and a set of outputs. LabVIEW schedules each node to execute when one item of data has arrived on all of its inputs. The execution of the node generates all of the outputs which then trigger the following nodes to run. There is no queueing on wires unless you explicitly put a queue primitive node on the diagram. Looping (using structures such as For-loops and while-loops) are explicit rather than being implicit like in some other languages.

So, in this diagram, you can see that everything is a node. Even the constants are nodes. Node 1, 2, 3, and 4 have no inputs, just outputs. So, when the diagram runs, they can go first because they aren't waiting on anything. Node 5 waits until Nodes 1 and 2 have run. Node 6 waits on nodes 3 and 4 to run and then it runs. Node 7 waits until nodes 5 and 6 have run and then it runs. Finally, Node 8 runs. Easy to show.

So how do you implement something like this? First, it depends on the hardware you are running on. As you can see, there are a number of things that can run simultaneously. Nodes 1, 2, 3, and 4 can all run in parallel with each other since they have no dependencies. Nodes 5 and 6 can run in parallel since they don't have any dependencies. In a processing environment that supports parallelism, you could run a lot of the diagram in parallel. Node 7 is a synchronization point. It needs to wait for two different parallel operations (node 5 and node 6) to complete before it can continue.

How efficiently you can run this diagram will depend on three things

How much parallel hardware is available. Can the hardware perform two adds in parallel?
The overhead of scheduling each operation
The overhead of synchronizing at Node 7

Silicon logic is probably the ultimate parallel processing technology. The FPGA makes this technology accessible to those without a semiconductor fab at their disposal and LabVIEW FPGA makes it accessible so you don't need a degree in a complex language like VHDL to use it. If you run this diagram on an FPGA via LabVIEW FPGA, it will specify that the FPGA should make two blocks of hardware that perform adds in parallel and then feed the data into node 7 to do the multiply. The scheduling and synchronization overhead will depend upon how you draw this diagram. In the above diagram, LabVIEW FPGA wants to be safe. It will take each output wire and turn it into a register. So, the add at node 5 will occur and the data will go into a register and wait for the clock tick to come in order to pass the data on to node 7. This is how the data is synchronized. The scheduling overhead consists of a signal that travels from node 5 to the register to tell it "data is ready" and the signal that travels to node 7 that says "ok, now you can go". it takes up space but doesn't affect speed.Now, it turns out that this safety is a little paranoid. It turns out that the two parallel adds complete is a very short amount of time. In fact, the two adds can complete in parallel and then perform the multiply all in just one clock cycle. Since you know that, you can put this diagram into what is known as a 'single cycle timed loop'. This tells the FPGA module to remove the overhead of the register between node 5 and node 7. So, FPGAs have a lot of parallel hardware and can nearly eliminate the scheduling and synchronization overhead. What's the downside? Every single operation consumes a little bit of hardware and the FPGAs aren't terribly big. That 100 VI project isn't going to fit. Also, there are some primitives that don't work in the FPGA.So what about microprocessors? A microprocessor is mainly a sequential programming engine. You give it some sequential instructions and it performs them. Some processors (like modern desktop ones) can extract a bit of parallelism from the sequential instructions. A Pentium can run a couple add or multiply instructions in parallel. Now that multicore processors are becoming more common, they can handle multiple sets of sequential instructions at once. How do you implement a structured dataflow engine in one of them? A basic dataflow scheduler has a big lookup table with a list of all of the nodes. It keeps track of which node feeds data to which and what data each node is waiting for. After each operation, the table gets updated with which nodes are waiting on which data and then which node is ready to run. In a paper I once read (that I can't find any more) this was called "fine grained dataflow". Easy, right? Well, yes but terribly inefficient. An "add" instruction in a microprocessor might take 1 clock cycle but the maintenance of that table may take 50 clock cycles or more. Having a scheduling overhead of 50:1 does not make for an efficient machine. Researchers have some techniques for reducing this overhead and some dataflow processors have also reduced the overhead in hardware. In the paper I read published many years ago, they stated that none of these techniques had really been commercially successful.

Now, one thing to notice is that computations are not particularly sensitive to the outside world. For example, if you can't execute node 5 and node 6 in parallel, it really doesn't matter the order in which you execute the instructions. You get the same answer and the operation takes the same amount of time if you do the node 5 add and then the node 6 add or vice versa. Thus, LabVIEW forms "clumps" of instructions which are all basically sequential and then only does scheduling when a clump of instructions is done (using something more efficient than the table lookup by the way). So, the LabVIEW compiler might emit something like

Put "4" in register 1
Put "5" in register 2
Put "7" in register 3
Put "8" in register 4
Add registers 1 and 2 and store it back in register 2
Add registers 3 and 4 and store it back in register 4
Multiply registers 2 and 4 and store it back in register 2
Store register 2 in memory somewhere
Look for the next clump to run

This is all sequential code. While it might have been possible for the "add" in #5 and the "add" in #6 to run in parallel on different processors, the overhead of now trying to send the instruction to a separate processor and keep track of the synchronization and scheduling is so huge that you wouldn't have gotten the benefit of running them in parallel.

Now, it so happens that this example is so small, that the folks at Intel and IBM do give us some parallelism. A Pentium has multiple instruction units. When executing this sequential set of instructions, it sees that the first sets of instructions use different registers. Thus, the operations to put numbers into registers will likely occur in parallel. It might only take 1 clock cycle to execute the first 4 instructions because they don't interfere with each other. Likewise, instructions 5 and 6 operate on different sets of registers and there are multiple adders inside a pentium. Thus, those two instructions will probably be executed in parallel in the next clock cycle. Instruction number 7 is where things get interesting. It can't execute until both 5 and 6 have completed. Thus, it can't execute in parallel with instructions 5 and 6. (In fact, on some older CPUs, there might be a multiple clock delay while it waited for instructions 5 and 6 to complete). Similarly, instruction 8 can't execute until instruction 7 is complete.

So, even on a single CPU machine, you can get some small amount of parallelism. As always, thank your Intel engineer for this.

Ok, so this article is getting long so I'll stop there. If you're a LabVIEW programmer, you hopefully understand a little better how things work under the hood. If you're a student of computer architecture or parallel programming (as I once was), always pay attention to the overhead of distributing your workload because it may swamp any savings you hope to gain.

Planning for failure

2006-02-22T07:51:00.000-08:00

I love my TiVo. We have two in our house and they are constantly recording stuff. I never thought I'd see the day when my kids preferred "educational" programs like Junkyard Wars and Mythbusters to cartoons but TiVo did it for us.

Recently, they have been adding new features to our box by way of automatic upgrades. Given that the TiVo really is an "embedded system", this is a bit novel. Now we have the ability to transfer movies to our PC, to a video iPod, to a DVD (by way of the PC). We can pull music from our iTunes libraries on our machines. Last week, we got a new set of features that provide access to the Internet. It allows us to look up movie times, buy movie tickets, see traffic conditions, and get the weather forecast. All of these options require connecting to the Internet but our TiVo is hooked to our wireless network at home so that's no problem.

Now, I don't know if these features are worthwhile. Really the bottom line is saving us walking the 35 feet from our couch to one of the computers to look this information up. But, weighing the merits of these features isn't the interesting part. When we found out about these new features, we poked through them to see how they did. Hmm, nice, the weather report seemed accurate. We did look up movie times and descriptions. Then we went to the traffic report and the screen didn't update. I can only assume the TiVo was waiting for something on the network and it wasn't responding. If you or I was looking up this data on a web browser and this happened, we'd mumble something about the site being down, close the browser window, and go on with our lives. Maybe, if it was some evil flash-laden site and closing the browser didn't happen instantaneously, we might have to get out the task manager and kill the browser process. It's painful but you can still be done in 20 seconds and back on to other things.

Unfortunately, these paradigms don't exist in TiVo world. There's no "cancel" button, no "quit" button, no "task manager". In fact, the TiVo doesn't even have a power button. It's always on, humming along, recording things that it thinks you might like. So what happens when an embedded system designed for unfailing reliability (you have to admit, not having a power button is quite a statement of reliability) meets something unreliable like the Internet? We had to pull the power plug on the TiVo. It took about 6 minutes for the box to come up, since it's very atypical for you to power off the box. Fortunately, it wasn't recording anything in the background or that process would have failed also. But probably the most damaging problem was to our confidence in that feature. Maybe traffic reports are a cool thing, but neither my wife no I will likely ever click on that button again. The "benefit" of not walking 35 feet has been dramatically outwieghed by the "risk" of losing 5-10 minutes of that very favorite show the TiVo might have been recording. The feature is now "too dangerous" to attempt and that's a pity.

So what's the moral here? If I knew the actual failure mode, there are probably engineering parables about error checking, robustness of coding, or something like that. But to the user, it's really a different story. This was not a coding error, it was a design error. The design fell over when something inherently failable failed. So, I guess my best advice for those amazing people at TiVo is, "plan for failure". Who says pessimism is bad?

Technocrati tags: TiVO, Embedded Programming, User Interface

Less can be more

2006-01-31T11:28:00.000-08:00

I admit to spending much more time than seems reasonable reading Slashdot. Is following commentary on Apple’s new MacBook Pro (horrible name but I want one anyway) really that good a use of my time? Sometimes, your brain just needs a break. Other times, you stumble across really good articles (check out Guy Kawasaki’s new blog). Joel on Software is running an update to the book he wrote years ago on design. In the introductory article, he mentions

Every new feature is a tradeoff, between the people who could really use such a feature and the people who are just going to get overwhelmed by all the options.

...even if you think your new feature is all good and can't hurt because "people who don't care can just ignore it," you're forgetting that the people who allegedly don't care are still forced to look at your feature and figure out if they need it.

LabVIEW is running into a bit of this. After 15 years, we’ve added a heck of a lot of things that are useful or even necessary for developers. They hopefully make your job easier or allow you to get things done faster. However, for those of you who are brand new to LabVIEW, all of those cool little options must be overwhelming. Sometimes we get a bit nostalgic for “LabVIEW 2” because it was simple.

Well, we’ve gotten a chance to think about what LabVIEW would be like if you strip it down to the basics and you can get your hands on it real soon now. My latest secret project is finally starting to reveal itself with the announcement of the Lego Mindstorms NXT. There are very few public screenshots of the software, but here are a few

In NI press release
This blog from CES

It will be very interesting to see the difference between a 12-year old using LabVIEW (via RoboLAB) and that same child using the Mindstorms product. I’ll bet we’ll learn how to make your lives easier too.

Technocrati Tags: User Interface, LEGO, Mindstorms, LabVIEW

Deploying LabVIEW Code

2006-01-24T08:25:00.000-08:00

One of the interesting characteristics of LabVIEW is that the source code to the application and the object code of the application are stored in the same file on disk. In languages like C or Java, the text file with the source code is run through a compiler to generate the code that can be executed by the computer. This code is stored in a separate file, an object file (the .o file) on disk. Once the source and the object files exist on disk, there is no real relationship between the source files and the object files any more.

LabVIEW comes from a different heritage. The code for the VI is stored in the VI file itself. Rather than the object code being a separate representation of the application, it’s more like a cache of the results the last time the VI was run through the compiler. There is no explicit “compile” step in LabVIEW. You hit run and it works, the rest is all magic under the hood. The executing code re-uses the “source code” of the application when it is running. It may open the front panel (which is, after all, part of the source code of the VI) and display it. You can open the block diagram of the application when it is running and probe wires.

As a LabVIEW user, then, you are only dealing with one file, the .vi file. It contains the ingredients you need to run the application and it contains all of the information LabVIEW needs to rebuild itself if the environment changes. You can give the file to someone else and they can use it. You don’t give someone else an object file and then have them say “but I want to modify it, can I have the source code?” It’s a very collaborative way of providing code.

However, the ease of distribution of a LabVIEW program does expose you to some interesting phenomenon.

What if you don’t want to give the person the source code? You don’t want them to see how you made the application.?
What if you want to bundle up the application into one file rather than a collection of files?
What if you want to make an application that can run without LabVIEW?
What if you want to make something small, without all of the source code in it?
What if you want to store the source files in a version control system?

As LabVIEW evolves, people want to do more and more with it. Thus, we need to keep up with the times. The current answers to these issues are:

If you don’t want to give the person the source code, you have two options. The first option is to password protect the VI. The second is to remove the source code of the VI. In versions of LabVIEW before 8, you could do a “save with options” to do this. In LabVIEW 8, you make a source distribution target and use the “Customize VI Settings” button to tell it to remove the block diagram (and/or front panel)
Normally, an application is a collection of VI files. You can manually take all of the files and put them into some archive such as a ZIP file, or you can save them into a LabVIEW LLB file using a deployment target.
LabVIEW VIs can be built into stand-alone applications. For that, you build an application using the application builder. This used to be a stand-alone tool but is now integrated into the LabVIEW 8 project as a deployment option
Making a small application is the same as items #1 and #3. The application builder will strip out all of the block diagrams and front panels automatically or you can do it manually through the source distribution as described in #1
Storing files in version control is still the most common question we get around this issue. LabVIEW does integrate with version control systems. However, a common problem is that the VI files may have to change even if the source code doesn’t change. This means that you have to check out the file and check it back in even though the source code didn’t change. It’s a known issue that we continue to look at.

Technocrati Tags: LabVIEW

Untitled

2005-12-05T12:53:00.000-08:00

As a developer, it's great to hear about new and interesting applications of LabVIEW. I remember a few years ago seeing on ABC news a story by the late Peter Jennings on a researcher giving movement to quadripalegics. The researcher monitored the brainwaves of the patient and used the patterns to send electrical impulses to the muscles of the patient. The patient could think to open or close his hand and the system would essentially be a replacement nervous system. He was able to open and close his hand, move his arm, and write his name. As the cameras panned across the equipment, LabVIEW was sitting there as the control system. It's very inspring to know that our efforts are resulting in change in the world.

I just heard about another system today that is impressive, just on sheer scale. The South African Large Telescope's control system was developed in LabVIEW. It's a system of over 10,000 VIs and allowed them to finish the telescope with many fewer programmers than if they had written the code in C. That's cool....

Technocrati Tags: SALT, Telescope, LabVIEW

Storing and Retrieving Data

2005-11-11T11:18:00.000-08:00

A few years ago, a colleague and I looked at all of the ways in LabVIEW you can store and retrieve data. The list was not only large but it was a bit embarrassing how incompatible all of the methods were. For example

Mechanisms for performing data capture

Print VI front panel, at completion or manually triggered
Generate screenshot of VI manually and paste into report
Log at completion, Use the front panel playback feature
Log at completion and use the "enable database access" function to retrieve the data
Generate report from front panel using reporting toolkit
Ascii Files - write to spreadsheet file
Binary file - write binary array to file
Load/Store XML file
Datalog File - write and read cluster using file primitives
Database Toolkit
DataSocket to File
LabVIEW DSC Module
LabVIEW Express File Storage VI

Whew. That's a lot. One thing that was frustrating when looking through this list is that there weren't many ways to store structured data. For example, it was difficult to take a lot of values, associate it with a "run" (time, date, location, etc..) and then store multiple "runs" in a particular place. I implemented it to an access database using the Database toolkit once and it was pretty time-consuming. Another observation is that there weren't many ways to browse the data that you had stored. There was the front panel datalogging "retrieve" function and there was the Citadel explorer in DSC but that was about it. You had to write a program in order to view the data you had stored. Various business forces combined to finally do something about this in LabVIEW 7.1 Our acquisition of GFS a number of years ago brought in a whole host of people experienced with storing and retrieving really large datasets. The two most important integrations between the two were

You can open LabVIEW data files (the LabVIEW "measurement file format") in DIAdem. It's a configuration based program that lets you retrieve and manipulate data sets. No more writing a program just to get your data back
The LabVIEW Data storage VIs. The object of these VIs was to allow structured data to be stored in multiple different representations. The data could be stored in a measurement file, a DIAdem file, or ASAM-ODS databases. And again, the data could be read from DIAdem without writing a program to do it.

Hopefully, this will give you leg up when you try and implement an application that reads and stores technical data. One day, I'd love to see you have a virtual notebook. Something you can use to store random bits of data but still be able to retrieve it and query it. Find all of the runs of data that gave you the answer "5". Ah, someday...

Technocrati Tags: LabVIEW, XML, Database, DIAdem

Stupid LabVIEW Trick - Swap Terminals

2005-10-19T11:02:00.000-07:00

Quick piece of trivia for those who might find this useful.

So you wired up a node, maybe even debugged it, and found out DOH! I wired them backwards (especially for a subtract primitive). There is a quick shortcut you can file away.

If you want to swap the wiring without deleting the wires and rewiring it, hold down the Control key (on Windows or similar key on the other platforms) and click on the top or the bottom wire terminal on the subtract primitive. Voila, the terminals get swapped.

Note: If you are not using the aut0-tool, you must have the wiring tool selected when you do this.

Shipping Software

2005-10-14T14:40:00.000-07:00

I became a "professional programmer" when I was 17. "Professional" because a freeware app I made got put in a floppy-disk based periodical and I got paid money for it. How cool. (Holy cow I found it KeyCapsGS - first published in 1988 I believe).

So since 1988, I've had to deal with the question of "when the heck is software done?" Well, metaphorically, software is never actually done. There's always 2.0, 3.0. But when you're working on 1.0, when do you decide to ship it?

As with all art forms, it depends on who's looking at it. I hope the software that controls the brakes of my car has zero bugs in it. Then again, all I really want is that there are no bugs that ever prevent me from stopping. So even safety critical software has some sort of acceptable bug threshold. If my screensaver applet crashes when I change modes, I may not even care.

So my answer is: you ship it when the quality level is acceptable to your customers (and possibly regulatory bodies that have some sort of say in the matter)

The concept of "acceptable level of bugs" doesn't sit with some people well. But again, it's a matter of perspective. The article quoted a study that found

...two separate people dissected one particular Microsoft program and found out, to their shock, that it was over 2,000% larger than it should have been.

Maybe Microsoft programs are indeed "bloated". But so what? Probably 100 people in the world really care enough not to buy their software. But if Microsoft went and rearchitected some application so that it met those folks' mythical standards, they probably would lose tens of thousands of sales to satisfy those 100 people. So calling software "done" isn't just a technical decision, it's a business one.

So the key is to understand your customer base. Understand what they need. Understand what they want your software for. Is it being used in a safety critical system? Is it being used in a screensaver? Your biggest risk in software is misunderstanding the quality that the customer expects and giving them something different. If they expect more and you don't give it to them, they'll avoid it like the plague. If they expect less and you give them more, you may have wasted development time that a competitor used to snatch those customers away.

LabVIEW 7.1 has a great reputation and we're all quite proud of that release. But not all releases hit the "meet customer expectations" mark. I presided over a version of LabVIEW that had a bug "fix" in it that caused an even bigger bug than the one it fixed. Whoops. (Fortunately we pulled the release and fixed it before anyone noticed) But in the end, our goal is always to make you happy.

The joys of symmetric multiprocessing

2005-10-07T12:39:00.000-07:00

In my End of the Free Lunch post, I mentioned how desktop CPUs are moving toward a multiprocessor architecture that will require major changes in the way programmers write software in order to attain higher performance. Well, this isn't just a trend in the desktop market. The embedded systems market is also seeing a proliferation of multi-CPU devices. At first, they were exotic boards that used parallel arrays for signal processing. Then, you saw hybrid systems with two chips (sometimes in the same package), commonly used in cell phone applications. Now you are seeing rather standard architectures with dual cores, like a recently announced PowerPC chip for military, telecom, and other embedded markets.

What does this mean for embedded systems? Well, opinions seem to vary. Enea encourages asymmetric multiprocessing (i.e. an OS running on each chip and different programs running on different chips) in their article "Who's afraid of asymmetric multiprocessing"

In addition, SMP is not well suited for many applications that require predictable, real-time response. It does not scale well to very large systems, and it lacks fault-tolerant features.

Firing back in the same magazine, QNX says:

By running only one copy of the OS, SMP can dynamically allocate resources to specific applications rather than to CPU cores, thereby enabling greater utilization of available hardware. It also lets system tracing tools gather operating statistics and application interactions for the multi-core chip as a whole, giving developers valuable insight into how to optimize and debug applications.

So whom do you believe? Well, it probably depends upon your application and your viewpoint on the world. Coming from a developer on a huge code base, I'm firmly in the SMP camp. Why? Well, first, LabVIEW already runs well in an SMP system. We put in a lot of work to make our application nicely multithreaded and I want our customers to be able to take advantage of it. The second is that moving an application from a multithreaded environment to an asymmetric multiprocessing system (AMP) requires a change in architecture. Changes in architecture are hard... Really hard. So I'm not "afraid" of AMP, but I'm certainly "annoyed" that I'd have to contemplate it.

Yes, SMP will never work across two different types of processors. That's what we've got LabVIEW 8 with Distributed Intelligence for...

Software that's built to last

2005-09-29T12:26:00.000-07:00

An article on the Windows Vista release tells the story of how Microsoft realized (belatedly) that their development practices no longer supported the release of their software. Microsoft lost a tremendous amount of time because their software wasn't flexible enough to handle the changes they wanted to put into it.

Take a look at the applications you use on a daily basis. When was "1.0" of your internet browser released, your email program, the instant messenger program, your music player. In many cases, it's only been around 4-5 years. "Windows", even the NT codebase, has been around since 1992. LabVIEW was first released in 1986. How in the world do you write code that still runs twenty years later?

Most software products change by the addition of features. We add new capabilities that customers are willing to pay money for. The ease of adding those features is directly related to the architecture of the code. A "good" architecture makes adding features easy, a "bad" architecture makes adding features hard. Unfortunately, it's not really that easy. When NI started writing LabVIEW, "networks" were in their infancy (remember ARCNET and token ring? NI actually used GPIB cables to send data between machines at one point). Who knew that one day we'd be doing data servers, remote panels, and web browsers integrated in to LabVIEW? Feature needs change over time. Unfortunately, architecture is much harder to change and it requires real work, it doesn't just happen on its own.

So, have you ever bought software with the bullet point "rearchitected for better developer maintanability!" I don't recall that one making it on "LabVIEW Key Benefits" list. Our customers don't pay for it directly and your customers don't buy your software because you made improvements. But, if you want your software to last, you need to invest in architecture changes. Features pay the bills this year, architecture pays the bills next year. Learn how to refactor, or else you will end up with a rewrite.

Remembering your work

2005-09-13T15:12:00.000-07:00

Whenever you have multiple developers working on the same file, be it a program source file, a graphics file, or even documentation, they are going to start stomping on each other at some point. A team typically turns to a source code management system (SCM) to help with this problem. However, most individual developers don't ever use these systems and that's a shame. The beauty of an SCM system is that you can still recover from an "oops" after you accidentally hit "Save" instead of "Save As...". You can get your precious work back if your filesystem corrupts that all important file. And, the way I use it most, you can go back and figure out why your system worked better before you added that last "feature".

I've used many different systems over the years but there are two packages out there that I recommend most for the personal user. They are both industrial strength (because you always end up needing it) but are user friendly enough that I think most any developer could figure them out. They are cross-platform. And, most importantly, they are both free for personal use.

The first is Perforce. We use it internally at NI and it's quite good. Even though it can handle our more than 5 million files, it really works well for just a few files also. You just download the client and the server and run them on your laptop, desktop machine, or whatever. It works over the network if you need it to.

The second is Subversion. It's an open source SCM system that is trying to replace the open source standby CVS. We're using it on the LabVIEW Embedded Development Module public repository and so far it's working nicely. It is much much easier to use than CVS but it has the features that I care about. There's a windows shell extension called TortoiseSVN that makes all of the management rather easy. I found a blog with some links that are probably useful.

Enjoy.

Behavior Changing Technology

2005-08-30T08:58:00.000-07:00

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.

Performance Hint

2005-08-16T05:00:00.000-07:00

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

Embedded stuff at NIWeek

2005-08-10T11:48:00.000-07:00

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.

What do you call yourself?

2005-07-29T10:12:00.000-07:00

I recently was out visiting developers, some who already used LabVIEW and some who don't, taking input on the LabVIEW Embedded Development Module. One thing that we know is that LabVIEW allows engineers to program a system even though they don't have a computer science degree or haven't spent years learning C or C++. Unfortunately, we don't have a catchy phrase to describe this class of person. In NI's traditional test market, we could call these folks "test engineers" and that was close enough. Yes, some test engineers knew C and some didn't but it didn't require splitting hairs.

But what about the embedded programming market? You can't currently program an embedded system unless you know C or C++. There's nothing else to use except for a tiny bit of Java and some oldschool ADA or assembly folks. Everyone could probably be defined as a Computer Scientist.

So who is LabVIEW enabling? We have taken to calling the folks that the LabVIEW Embedded Development Module enables "domain experts". After all, they have a lot of valuable knowledge (expertise), even though it isn't in C programming. They have expertise in their domain, be it control theory, biology, mechanics, chemistry, signal processing, whatever. Unfortunately, this term doesn't seem to be understood generally. One person said to me "I saw the word 'domain' and thought you meant the Internet". Hmm, not quite what we had in mind. Other suggestions have been "System Architect" though I'm not sure if that resonates. LabVIEW allows people with big picture knowledge to implement the system but we do expect the person to know some low level details of how the thing actually does work. "Application programmers" in my opinion would be assumed to be computer scientists. "Signal processing" engineers certainly like LabVIEW but that's too narrow.

So, what do you call yourself? If I called you a "domain expert", would the label fit? Would you be offended? Does it sound too grand? Not grand enough?

Poll: Show Buffers?

2005-07-19T15:07:00.000-07:00

LabVIEW has programming semantics of "by value". Data on a wire represents the "value" of that thing. You don't have "pointers" to data. You don't typically have "references", except when you are referring to certain objects like files or controls. Being a by-value language rather than a by-reference language makes programming in it less error prone and easier for folks to understand. However, for programmers experienced with languages that make extensive use of by-reference semantics (C & C++ come to mind), it requires a mental shift that some of them aren't happy with.

But I'm not going to start that debate. Instead, I'll talk about the implication of by-value semantics. Let's take the basic case of adding two arrays.

The semantics are easy, input 1 and input 2 are arrays. They get added together and placed into the output indicator. Now, a C programmer would look at this and say "aha! After an item in Input 2 is looked at, it isn't needed any more. I can save memory by taking the result of the addition and storing it back in the memory that was used for Input 2". That is a nice optimization. Unfortunately for the C developer, they would have to write their algorithm differently in order to do that optimization. They would have to store data back into the array by effectively using references.

In LabVIEW, there's no way to get a reference back to Input 2 and store the data back there. We really don't want you to do that anyway. Instead, we'd rather have LabVIEW figure it out and do it for you. And that's exactly what we do using something we call "the inplaceness algorithm". This algorithm figures out what memory locations can be reused to make the application take less memory and run more efficiently. Is this algorithm perfect? No. Does it work? Yes, quite well in fact.

We added a feature to LabVIEW in 7.0 via DevZone and as a true menu item in 7.1 to let you peek under the hood of LabVIEW and watch the inplaceness algorithm work. If you select Tools-->Advanced-->Show Buffer Allocations... you can see this tool in operation

It shows you all of the places that LabVIEW decided that it couldn't reuse memory and had to create another buffer to hold the output data. I will say that this is an advanced tool. It doesn't interpret the location of the buffers, it just shows you where they are. It is not possible to get rid of all buffers, don't try. :-) You can find out a little more about how to use it by clicking the help button or looking at this help link. The LabVIEW Memory Management Application Note also gives you insight into what is going on.

So here's a question for the audience. Have you used this tool? Is it helpful? What else would you want to know? (no promises here folks)

Writing Parallel Programs in LabVIEW - Part 1

2005-06-29T14:41:00.000-07:00

In my post about how the CPU business is going to multi-core processors, I talked about how LabVIEW can help things. Here's the first in an occasional series of things I can think of that help LabVIEW applications run in parallel on multi-CPU machines.

1) Read the paper about Hyperthreading and LabVIEW. That shows you all about the LabVIEW threading model, clumps, and how to write some basic applications that do run in parallel.

2) Learn about re-entrant SubVIs. Normally, a VI that is called from two places in parallel will not actually execute in parallel. Otherwise, the data from one iteration would stomp on the data running in the other. Therefore, you need to mark the VI as re-entrant.

There's a hard way and an easy way to do this. The easy way is to go to the VI properties and mark the VI as re-entrant, then drop down the VI in all of the places you want to use it. This was shown in the Hyperthreading and LabVIEW paper.

But what if you don't know how much parallelism you want when you write the program? What if you don't know how many channels you are going to run in parallel?

One application note on this is Multi-Tachometer Processing with the Order Analysis Toolkit. Order Analysis is accomplished through a long computation (FFT). If you have multiple channels, you can compute multiple channels in parallel on a multiprocessor machine. Add more processors, compute more channels in the same amount of time. This appnote shows you how to dynamically add more parallelism based on the number of channels you are processing.

3) Make sure you don't get serialized in Call Library Nodes either. If a Call Library node isn't marked as threadsafe, LabVIEW will serialize calls to the DLL. However, unlike a VI, just changing the Call Library Node to reentrant is NOT a good idea unless you are positive the code is really threadsafe. If it is threadsafe, then it's always a good idea to mark the Call Library Node as reentrant. There is no downside (and there's a big performance boost to marking a Call Library Node reentrant).

4) Be judicious in your use of re-entrant SubVIs. If your VI that you want called in parallel calls other VIs, you may need to make those SubVIs you call re-entrant also. However, it's a bad move to mark absolutely everything as re-entrant. When you do that, it causes extra copies of every single VI's dataspace to be created. That can result in a HUGE memory footprint and you won't realize it. Therefore, be selective. Use the profiler to help determine which VIs should be marked as re-entrant. The VIs that execute for a long time (or have children that execute for a while) should be marked as re-entrant if there is any chance they will be called in parallel. The short quick VIs can be left as normal since they won't typically get called simultaneously or, even if they do, they won't block for very long.

There are some other tricks but I'll save those for another time.

Lessons from other industries

2005-06-19T16:39:00.000-07:00

You can learn a lot just watching the mistakes of others. Here's one I hope we never make: forgetting the reason for your company's existence.

I'm a car-nut. I've spent my life pouring through the pages of auto magazines. I asked my dad to buy a Ferrari when I was age 10 (he didn't go for it). I've been to the Indy 500, drag races, NASCAR at Watkins Glen, and a host of other events. Today, I watched what happens when a group of folks forget why they're around. At the US Grand Prix Formula One race, one of the tire manufacturers (Michelin) screwed up. They brought tires that were unsafe for the track and couldn't fix it in time for the race. The various power players butted heads, couldn't reach an agreement, and so the Michelin teams didn't race. The "Grand Prix" consisted of a grand total of 6 cars starting and finishing the "race", if you could call it that. The fans were livid. They changed their schedules and paid anywhere from a few hundred dollars to a few thousand dollars to be there.

If there were zero fans in the grandstands and zero viewers on TV, the decisions made by all involved were probably correct. Neither Formula One nor the other tire manufacturer (Bridgestone) should have had any reason to accommodate Michelin. Michelin screwed up and the teams that relied on Michelin were wrong by having no fallback position. Motor racing at its purest is Darwinian. Those that are unprepared should not succeed.

But, it's obvious that all people involved (Formula 1, Michellin, Bridgestone, the head of the various organizations, the lead team owners, etc..) have forgotten why they pour billions of dollars into the sport, it's for the fans stupid. Teams won't spend $400 million/year if there's no audience. If they had cared about the fans, they would have forged a real compromise and allowed something that allowed the fans to be happy. Not because it was the proper racing thing to do, because it was the proper way to treat the fans. Instead, they put their competitiveness above all reason on display for the world today. Today I think they killed the golden goose. They forgot who pays their bills.

The End of the Free Lunch

2005-06-14T11:17:00.000-07:00

Ok, so there's No Such Thing as a Free Lunch but in the computing world the processor vendors like Intel were buying lunch for everyone. I headed up the LabVIEW Performance team for about 2 years and had a pretty easy job. All our group had to do to make LabVIEW faster was to wait 18 months and let Intel double the speed of their processors. It almost made cutting 20% off of some array manipulation feel rather worthless. As you've probably been noticing, that 4 Gigahertz Pentium that you were expecting never quite happened. We've been stuck at 3.2ish GHz for quite some time now. So what's going on? CPU vendors have discovered that they can't keep increasing the clock rate the way they used to. In fact, their entire paradigm for extracting more speed has fallen down. Thus, they've all changed course and gone dual core. Now, instead of doubling the speed, they are going to give you two processors next year for the same price as one processor this year. But does your software still get twice as fast?

Well.... maybe. Software written in C needs to be specially written in order to take advantage of the second processor. Windows XP, MacOS X, and Linux all support Symmetric Multiprocessing (SMP). This allows chunks of code to run on either processor without the software noticing which processor it is running on. The smallest "chunk" that can run on a different processor is known as a "thread". In C, you split your code into different sequential paths and call some extra libraries that schedule those paths using the separate threads. If you do this, you call your application "multi threaded". LabVIEW became a multi threaded application in version 5.0 and ran on SMP computers. In the past 6 years multiprocessor machines have been rather rare. They were typically server machines that were four times more expensive than typical desktop machines. This may have been rather fortunate because it takes a while to get the kinks out of your software. We found all sorts of bizarre bugs (both in hardware and in software) on multiprocessor machines. Once Intel started putting Hyperthreading in their desktop processors, we saw average users have SMP machines.

Now, I mentioned that C code needs to be specially written to take advantage of multiple processors. What about LabVIEW code? Getting code to run correctly and more quickly on a multiprocessor machine requires code to be scheduled for correctness and maximum efficiency. In order to get the code to run correctly, the system needs to only schedule chunks of code to run when the data is available. In short, it needs to know the data flow of the program. That's what LabVIEW does. It schedules your code using data flow rules. Thus, on a multiprocessor machine, data flow code will execute correctly. (Note: you've learned all along that globals in LabVIEW can be bad... This is yet another place that they become bad). Using data flow rules, LabVIEW will automatically figure out which code can run independently and start both chunks of code running at the same time. Remember my example about parallel while loops? On an SMP system, these loops will run completely in parallel on separate processors. There's no need to share the processor so there's no need to ping-pong back and forth.

Thus, LabVIEW programs will automatically spread themselves across multiple CPUs. You don't need to do anything. There are some NI customers who see the speed of their applications double when adding a second processor (or triple or quadruple when adding a third or fourth). So, does Intel in combination with NI give you a free lunch? Maybe. It turns out that not all programs get that nice speed boost when adding an additional processor. I'll give you some tricks in the next article.

Abstracting the hardware

2005-06-09T08:23:00.000-07:00

Tuesday was a very big day for my group and the timing is rather interesting.

Monday, Apple announced they were switching from PowerPC to Intel x86 processors. Mac software developers everywhere were both overjoyed that they were getting a faster processor and dismayed that now they have to do some work just so their software keeps working. Software is very sensitive to its operating environment and needs to be modified or recompiled when the environment changes in unanticipated ways. Fortunately, changing processors is actually less of a problem these days than changing operating systems. Applications written in C on WindowsCE basically runs on MIPS, X86, or ARM systems. It needs a recompile and it needs to be tested, and tested, and tested (write once, test multiple). Software written in interpreted languages like Java, Javascript, or PHP don't even need to be recompiled. They just need to be tested on the different platforms. It's the testing, though, that can eat up a lot of time and expense. Why all the testing? There are subtle differences between each implementation of the environment. Javascript apps run differently in Internet Explorer than in Mozilla. Java apps have different environments on Sun versus Windows versus Mac.

LabVIEW (the code representing the development or execution environment), over its history, has been shipped on Macintosh (68k and PowerPC for MacOS "Classic" and MacOS X), Win3.1 through WinXP (x86 CPUs), Sun Solaris (on SPARC processors), SCO Unix, Linux, HPUX (on PA-RISC), Concurrent PowerMAX, PalmOS, PocketPC (ARM), Windows CE, RTX, and PharLap. In fact, it has outlived most if not all of the compilers used to create it. Every time we ship LabVIEW, the testing needs to be duplicated across each platform, at least for the places the are different between them. Over time, we've dropped some platforms when the sales we got from that platform no longer covered the cost of testing and support.

Sometimes, we do ports of LabVIEW internally to satisfy some curiosity or as a one-off experiment. We did a version of LabVIEW with the Jet Propulsion Laboratory to see whether it made sense to write software for space flight applications in G. The experiment is still going on but the results look promising.

We have talented developers but at the end of the day, you can only support a limited number of configurations. We commonly get requests for LabVIEW to run on some hardware that we don't currently run on, be it a military VME controller running VxWorks, an automotive telematics system running QNX, or an engine controller for a train running a custom operating system. Building a new version of LabVIEW to run on these platforms just hasn't been an option. Before today, we always had to say no. But today we announced the LabVIEW Embedded Development Module and we don't have to say "no" any more.

Over Christmas break, when no one was around, I got a week to play. I took a development version of the software and found the cheapest embedded target I could: a Linksys WRT54G router. $69 from Frys. Linksys runs Linux on the box and some enterprising hackers had figured out how to write applications that would run on the unit. It took me a little bit of time but in about a week I had adapted LabVIEW to run on the unit using the Embedded Development Module. When I hit the run button on my VI, it would take the VI, convert it to C, script the compiler for the platform (GCC) to build the application, call some scripts to download the code to the router, start the program running, open a TCP/IP connection back to the host, and let me interact with the application just like I was talking to a LabVIEW RT target. I had a new toy and grinned ear to ear. LabVIEW running on a router of all things. Even better, it ran as a multitasked application so my Linksys box actually routed packets while my application was running. The Linksys box has no real I/O but it has 5 Ethernet ports and a WiFi antenna. I'm sure someone could do something with it. The best I could do was write a program to control an ENET-GPIB box connected to an instrument. $69 instrument control. How fun.

Linksys also makes a device with an Ethernet connection and a USB master connection. Wonder what I can do with that USB port....

Weak Linked Languages

2005-05-25T08:19:00.000-07:00

As I watch LabVIEW build.... and build... and build... it reminds me of why C++ is the wrong direction for computer languages. I stopped getting C/C++ Users Journal a few years ago because each issue was more depressing than the previous. The trends shown in that magazine were toward an ever increasing amount of templating. I don't object to generic programming. I do object to the way that C++ does it. C++ aims for maximum generated code efficiency by trying to include and inline everything. The more the compiler knows during a pass, the better code it can generate. This has two problems. First, C/C++ compilers work on one object file at a time. The only way to give the compiler more information to work with is to put more and more information into each object file (via the #include statement). More information for each object file means slower compile time for the object file. In a source base the size of LabVIEW, that adds up to a ton of time. The second problem is that it couples all of your source files together. If you make a change to the implementation of your "list" class, the implementation of that class is inlined into every single source file, necessitating a rebuild of every single source file. The build/fix/debug cycle becomes 30 minutes for every line of code you change. That's a productivity killer.

There is a whole class of languages that doesn't work that way. I call them "weak linked" languages. These languages try to have minimal dependencies between objects. They give up a little in run-time efficiency because they have to discover some things at run-time that C++ programs set at compile time but the programmer productivity tradeoff is huge. Languages like C#, Java, and LabVIEW only make you "compile" the file that you just touched, not the other 5,000 files that may come in contact with the file you touched. Build/fix/debug in LabVIEW is 5 seconds for just about any change.

Beyond compile time, weak linked languages give you some other cool benefits. Notice how in LabVIEW, you can open a heirarchy of 200 VIs, go to any one of them, and hit the Run button and run the thing? A weakly linked language gives you that flexibility. Java has something a bit like it, though it's IMHO inferior :-) Any class in Java can have a "main()" function. From the command line, you can just start up the program by calling any classes main(), not just the one big entry point that is supposed to start the program. The JUnit framework takes advantage of that benefit to make a nice unit test system.

Just as programmers gradually gave up assembly language to get more productivity (and more maintainable code) in spite of a slight loss in run time efficiency, languages like LabVIEW are the way programming will be done in the future. The folks around me who program in G already know that.

Benchmarking a LabVIEW Operation

2005-05-19T13:49:00.000-07:00

A few years ago, I added an aside to an NI Week presentation about how to benchmark an operation in LabVIEW to see how long it would take. I wish I had written that information down because it's rather nuanced and you can easily shoot yourself in the foot if you don't have a checklist. So, for the benefit of my own memory and hopefully something for you, here's how to do a benchmark in LabVIEW.

1) LabVIEW is not a sequential programming language. I repeat, LabVIEW is not a sequential programming language. It does not execute left to right. It does not execute top to bottom. Forget this at your peril.

2) Therefore, always use a sequence structure. The recently added flat sequence structure works really well for this. Do not allow any code to stray beyond the border of the sequence structure because it could easily run in parallel with the thing you are trying to measure.

3) I recommend the structure shown below. It has 5 phases: initialization, record the initial timestamp, do the stuff you want to measure, record the ending timestamp, and clean up. The structure of the 2nd and 4th frames shown are very important. If you put anything else in them, you have no way to know if it ran before or after the timestamping code (re-read rule 1 three more times for good measure)

Proper Benchmark Template 1

4) Always Save All before running the benchmark. This is mandatory. Why? Because any VI in memory that has any modification will have some extra bits loaded that affect performance. For example, a VI that needs to be saved (maybe you changed a connector pane on a different VI and that caused a ripple) will cause LabVIEW to load the front panel of the "dirty" VI into memory, even if it's not visible. If a front panel is in memory, LabVIEW sees "hey, front panel controls are here, I'd better make sure they stay current" and so when the VI runs, it will force updates to all of the front panel elements, even if the front panel isn't actually visible. I can say this is the number one reason that I used to have someone tell me that the newest version of LabVIEW was slower. They loaded their old VIs into a new version of LabVIEW, hit "run" and it ran slower. They hadn't done a "save all" first and so every VI in their hundred VI heirarchy had the front panel in memory and ran slowly.

5) Close all front panels. This bit me and Steve Rogers when we ran a benchmark a month ago. We couldn't figure out why this new thingy he had added didn't benchmark any faster. We were dumbfounded for 15 minutes until we realized "doh!" the subVI front panel was open and so it was redrawing a few thousand times during the test.

6) Don't put any controls or indicators in frame 3 of the benchmark template above unless you are trying to benchmark the drawing time of an indicator. Indicators update asynchronously and will have a random effect on your test.

7) If you are benchmarking the drawing time of an indicator, you will have a trickier time. We do a lot of stuff to try and keep you from shooting yourself in the foot with drawing. Sure, you wired that output to the indicator, but did you really mean to redraw the indicator 50,000 times? Thus, LabVIEW will not stall the diagram waiting for the indicator value to update. It will only transfer the data from the block diagram to the indicator periodically. It will only redraw the actual indicator every so often (your eye can't see an update rate faster than 60 or so Hertz anyway), etc.. So, read up on "Defer Panel Updates" in LabVIEW help as well as the "Advanced->synchronous display" option in the context menu for the control. I will tell you that "Synchronous Display" does not (in spite of the tantalizing name) truly lock the diagram to the control. It just means that if you try and write to the indicator twice, it will stall the diagram the second time around until it has finished updating the indicator the first time. But, it will then let the diagram continue before it has completed drawing the second time. If you use the "Value" property for the indicator, it does send the data to the indicator immediately but I'm not sure if it waits until the drawing is done (it very well may, I just can't remember). Anyway, as with all things, we are always trying to improve LV performance in lots of different use cases without messing up existing code and so it's a very tricky balance.

As always, I hope this is helpful. I happed to be working on this type of thing today.

Intro

2005-05-17T08:26:00.000-07:00

Just a little bit of introduction. I thought I'd do this blog to give folks some insight into LabVIEW, how to get the most out of it, and interesting things that are going on in my area.

I graduated from school 12 years ago, spending 3 years as an application engineer at Motorola Semiconductor (now known as Freescale) writing networking microcode, doing customer support, and writing appnotes and documentation. From Motorola, I moved to Metrowerks to work on computer game development tools and eventually managing all of the game tools development there.

I started at NI about 6 years ago, initially working on improving LabVIEW performance. After managing the Performance team for a while, I helped out the NI-DAQ 7.0 effort for a few months and then managed the LabVIEW Real Time and Embedded teams (PDA, FPGA, RT). Now, I focus exclusively on getting LabVIEW in places it hasn't been before. PDA is still part of the mix as well as the LabVIW DSP Module that was just released today.

I hope some of this information is of use. Feel free to comment on anything.

55ms

2005-05-16T20:25:00.000-07:00

Each node on a LabVIEW data flow diagram will execute at some point
after its inputs are valid. That simple specification is sufficient
to guarantee that the computation for each node is correct. A program is
a collection of nodes. If all of the computations for all of the
nodes in your program are correct, can your program be incorrect?
Yes. When your program is interacting with the real world, it starts
dealing with another aspect of programming: time. Until LabVIEW 7.1,
time was not mentioned in the LabVIEW language. Libraries might have
mentioned it, but the language did not.

The way a diagram executes in time has always been a side-effect of
the way LabVIEW happens to work. LabVIEW uses data flow rules to
schedule parallel nodes to run in parallel. You notice this most when
two traditional "for" or "while" loops run in parallel. There is no
specification on how these loops will run with respect to each other.
While there is no spec, you probably should know how it actually
behaves. On the desktop, LabVIEW will ping-pong between loops every
55ms unless the loops have explicit wait primitives in them.
If you are writing a program that is communicating over the serial
port and has to respond to an incoming character in 30 ms, you need
to write your program in a special way to make sure things happen the
way you want them to. Here are a few rules to live by

1) Desktop operating systems tend to "hiccup" at undesirable times.
Windows will occasionally steal control for 100ms from applications.
While drivers like NI-DAQ can take steps against this, applications
like LabVIEW can only avoid that problem by running on a
deterministic OS such as the one used in LabVIEW Real-Time.

2) In LabVIEW 7.0 and before, run your time critical code in a
separate VI and set the execution system to a high priority (but not
subroutine). VIs in higher priority execution systems do not ping-
poing with VIs in lower priority execution systems. The higher
priority VI can take all of the time it wants.

3) In LabVIEW 7.1, take advantage of the timed loop. It allows just
that part of a diagram to run at high priority.

4) If you can't use high priority VIs or timed loops, then you need
to do it the hardest way. You need to make sure that no element of
your code can take more time than your minimum response time (30ms)
in this case. All library calls, all loops, etc.. must either
complete in less than 30ms or must yield time by doing a "wait".