Interview

Every other month Test and Measurement World has a Test Voices section where they interview different test engineers.  The engineers they talk with aren't necessarily the top of the field, just people working on interesting things.  For November's issue they talked with me about the testing I do at my current employer.  I have to say the process was enjoyable, interesting and efficient.  If you're interested, the interview is here.

Blog Action Day - Water

The past two years I've participated in Blog Action Day (2008 - Poverty, 2009 - Climate Change).  On both times I've tried to relate it somehow to testing or technology.  This year's topic is water.

When I considered water in terms of testing, I first thought about all the DI water that's used to clean DUTs.  Then there's the various water-cooled systems I've used over the years.  I've also met people in the New England area who test fuel cells - they are often concerned with how well the water the cell produces is evaporated.  So water is a regular part of my field, one way or another.

But then I ranged farther afield.  When I first moved to this part of the country, I had to test the water in the new house since it was well-based.  Biologically, it was okay.  There was a fair amount of sediment the pump sucked up, so I had a filter installed.  But the worst part was the radon.  There's a LOT of granite rock where I live, and granite rock can have trace amounts of uranium.  Radon is a decay product of uranium, and there was some of it in the basement as well as the water.  I installed a system to keep the radon out of the air, but filtering options for the water were too expensive.  I settled for "use it, but don't drink it."

What I'm trying to say is that we use a lot of water at work, and even the water we drink has to be filtered somehow.  The United States is about the top of the food chain economically.  Imagine what problems people may have with water if they don't have our resources.  Very sobering.

Bucket list: citizen science

Back in June I wrote a post about my Test Engineer Bucket List.  One of the items on that list was "Develop a test system that measures a fundamental aspect of the universe."  I think I've found an indirect way to scratch that particular itch: citizen science.

In the August issue of Dr. Dobb's I read an article about a recent success of the Einstein@home project: a new pulsar.  Very cool.  Also, in the June issue of Wired there's an article listing six different astronomical projects - also very cool.

I doubt any of these projects would give me a rush like building a calorimeter that sat inside the beamline at Fermilab, but it could still be fun.  Maybe I'll discover a black hole.

Visual Programming and LabVIEW, part 2

In Friday's post I wrote about the latest LabVIEW version, my reactions to it, and some thoughts on graphical programming.  This weekend I thought more about that conversation and wrapped it up with what I think LV should look like in the (near) future.

I applied for the App Inventor for Android, but I've read it takes a while to get approved for it.  When I get it and play around with it some I'll probably write a post about it.  But getting back to the Cube language thing from Friday, last month I started asking myself how would this translate to LabVIEW?  First I made a little logo, since that's the most important part.

Then I started thinking about how it would look.  It should be a stylized 3D environment: zooming in and out, pan and tilt, looking at it from top, bottom, front back, etc.  Then I started defining some details:

• Navigation: As I just said, it would be a 3D experience.
• You could spin the entire wire layout like you spin around a 3D graph
• You could "peer inside" a subVI object by making it slightly transparent
• You could "zoom" into or out of subVIs
• Icons: All the current LV icons should probably just be 3D renderings of their current 2D versions.  But user-defined icons... THAT could be the cool part.  Imagine designing an icon for a subVI that, instead of a small square with a little image and text inside, is a 3D image of the test equipment it uses (provided by the manufacturer of course).  You could even swivel around to the back and see all the plug in options.  Cool, huh?

3D image icon of a Keithley 2400

Stylized 3D icon

• Debug:  This option could be very slick.  When debug is turned on, you could have the option of "following" data travel from a "first-person-shooter" perspective.

Still a classic

• Optional: It might need to be something you could turn on or off, depending on the speed of the computer's graphics processing.  Turn it off, and you're back to the 2D version of the flow.  
• This also gets down to the choice of whether the 3D view is superficial or impacts how the block diagram is compiled.  If it's just visual, then you're fine.  If, however, certain aspects of your 3D model impact how the program runs (see, for example, "Flow" below), then you might lose that if you turn off the 3D viewing.
• View hidden items: The "hidden" frames of a case structure, event structure, etc., could be viewable as stacked items behind the front of the structure.  It could appear perhaps as slightly separated index cards, with maybe the option to fan them out like a poker hand (which would look very cool).

Error case viewed from the front, maybe 30 degrees above the plane

• Data Flow: This might be a tricky one.  One of LV's defining paradigms is data flow, and style guides suggest left to right.  But what happens if you can also go towards or away?  Should there be a switch in the compiler that says that code "behind" other blocks is not as preferential and should run "as time allows."  Or perhaps data on a tangentially angled line travels more slowly?  I think there are several games you could play with that idea.
• Layers:  Mechanical modeling programs, imaging programs, and semiconductor layout programs all have the concept of layers.  Different things happen on the different levels.  Could we do something similar with LabVIEW 3D?  I alluded to that idea with "Data Flow" above, but maybe it should be more concrete.  
• What if you defined separate layers for DB interfacing, hardware control, etc?  But instead of switching to those different different layers, you could see them physically: just zip over to that layer with your mouse.  
• Or how about, for multi-core programming, coding on those different layers happened on different processors?  
• There are certainly other tricks you could do.

I really like this idea of a true 3D interface.  I think the computing horsepower to do nowadays, it could improve the quality of LV programs by letting you see more details of the code, and it would be really fun to program in it.

Will this happen?  Who knows.  But if NI starts working on it, I want them to know that they heard it here first.... can I get royalties on that?

Visual Programming and LabVIEW, part 1

This is a long post, since I'm covering several different ideas I've had the last few weeks.  I'll break it up into two separate posts this weekend.
-----------------

LabVIEW 2010 is out, I've installed it, and I've played around with it for a month.  Frankly, it leaves me a little blah.  Yes, it has some speed improvements (but they improve the speed some every year) and some nifty new features (listed here) I can use.  But there is no real wow factor for me.  Maybe I'm jaded, but the last few LV releases have been solid stolid improvements on an existing edifice.  I really liked the project concept in LV8, I applauded the object oriented programming support in LV8.2, and I thought the new icon editor in LV2009 was long overdue. NI has been releasing a lot of useful, individual features each year, but there has been no overarching theme.  I'd just like to see something more from a graphical language.

I'd felt this way for the past year or so.  Then I read an article last month in Dr. Dobb's Journal about Google's App Inventor.  I followed this link to a 15 year old article about the cube language, written by a guy who now works at Microsoft.  These two items sparked some ideas.

That's enough for tonight.  Tomorrow I'll write what I think NI should do with a future version of LabVIEW.

The changing face of online content

Although it doesn't directly relate to test engineering, there was a good Newsweek article last month about how blogs, twittering, and crowdsourcing in general is changing.  Indirectly, it relates to what I wrote on my 3-year blog anniversary about test engineering blogs.

(more) Test humor

Sometimes when you're testing things, you have to come up with an "innovative" fixture.  This website really appeals to that part of my career.

Out of my jurisdiction

I spent some time the last couple of weeks researching large scale chip-level testing.  I needed some information for a new project, so I dug around online.

I'm no stranger to wafer-level testing or semiconductor issues - I've been doing that for many years now.  But after digesting the information I found on , I have to say two things.  One, the test issues those guys face are out of my current jurisdiction.  Two, it's pretty cool stuff (see also here) and I'm enjoying learning more about it.

If you want to do some more digging on your own, I would suggest starting with Chip Scale Review and spread out from there.  Also, take a look at this definition of automated test patterns as well as the interface language some large test systems use.

"Today, my jurisdiction ends here. Pick up my hat."

I want a tricorder

Android Tricorder App

Last year I compiled a list of tools all test engineers should have.  That list came to mind a couple of months ago when I got my spiffy Droid Incredible phone and downloaded the Tricorder app.  It's a VERY cool tool/toy, especially for a test engineer.

I was reminded of that list again when I read the "New Age of DMMs" article in Evaluation Engineering.  The title implied to me that there was a new line of DMMs I didn't know about.  Sadly, it didn't deliver on that promise - I already knew about PXI DMM cards and the new capabilities they had.

But what about new handheld DMMs?  So I checked out Fluke (of course), and they have a couple of neat multimeters I hadn't seen before.  The Fluke 289 is a good DMM that has logging capability with a TI-calculator-type graphing option (it got a Best In Test award in 2009). Even better, the Fluke 233 has a slick wireless option - you can hook it up, put the display in your pocket, walk up to 30 feet away and still read what it's measuring.

Fluke 289

Fluke 233

Both of those would be nice to have.  But I still want a tricorder.

Testing rebound

There was an article on Test & Measurement World last week that points out how the major test equipment manufacturers (Agilent, Tektronix, Fluke, etc.) are rebounding from the last year or two.  I would think that this means that test engineering as a career is rebounding as well, since if companies are buying the equipment, then there are engineers needed to spec it, set it up, and run it.  This rebound syncs well with the up-tick I've personally seen in job openings in the Boston area.  Food for thought.

LabVIEW 2010? Not quite yet...

I feel sort of bad for picking on National Instruments, after what I've written the past couple months (here or here).  But I'm annoyed and need to vent.

NI released LabVIEW 2010 this week.  I received an email saying that, "for immediate access, download your new software online at the Services Resource Center."  I had a new computer running Windows 7, so I decided to try the 64-bit version of the new software.  The download and install took several hours but appeared to work fine.

Problems occurred, however, when I tried to open one of my projects.  As soon as I opened the top level VI, LabVIEW started requesting subVIs from toolkits that I had a right to have - database toolkit, report generation, etc. - but were not installed with the download.  So I called NI support and they suggested downloading the toolkits individually.

No luck.  NONE of the toolkits are 64-bit (except I think vision), therefore none of them will work with my 64-bit install.  NI is working on it, but it isn't there yet.  When I asked the NI support guy if all the time I spent downloading, installing, and setting up was therefore wasted, he just said, "that is a true statement."

Misleading specifications

I've been learning more about solar cell testing over the past year.  I have a couple of test systems I'm developing, I've taken data, and it's been interesting.  It's also been frustrating.

As an example let's consider I-V sweeping, the bread and butter of semiconductor testing.  Most of the basic values of a solar cell can be determined from a quick IV check.  One of those values, the short circuit current (I_sc), helps determine the maximum power a cell could theoretically produce.  A high I_sc is nice to have.

When I first looked at measuring IVs for solar cells last year, I tried to re-purpose my National Instruments PXI chassis to this task.  I knew that the source measure unit (SMU) in the chassis (PXI-4130) could only go up to about 1A, but there was an auxiliary supply that could plug right in to the SMU: the PXI-4130 Power SMU.  On the NI page for the aux the output specs are listed at "12 VDC, up to 5 A, up to 60 W, 0 to 55 °C" (note the "5A" limit).  So I bought the aux supply and got started testing.

But as I tested larger and better cells, with more total current output, I ran into limitations with the NI approach.  I couldn't measure an I_sc above 2 amps.  This confused me somewhat, since I had seen the the five amp limit on the NI page.  Adding insult to injury, I didn't even need the SMU to output that current - the solar cell was generating the current.  

I then considered connecting multiple SMUs.  There is a "knowledge base" article on the NI website that supposedly answers the question, "What is the Maximum Voltage and Current that the NI DC Power Supplies can Source when Cascading Outputs?"  But nowhere on that page does it list a maximum current.  I even found a Photovoltaic Solar Cell I-V Characterization Bundle page that says you can "add more SMUs to get three times the voltage or current."  I struggled with this problem for a month.  

Well, I finally got an answer from NI last week.  The SMU cannot measure above 2A current because the PXI chassis has to dissipate the power, regardless of where the current source is.  The chassis has "a hard limit on the amount of power consumed by each of the SMUs."  In other words, National Instruments has some cleaning to do on their website.

------------------------

So what's the moral of this rant?  First, I'm going to get a different power supply (maybe Agilent).  Second, you cannot always trust the hardware verbage you read online.

Check your test equipment

I heard about a perfect example of #1 on my test engineering fears list on the radio the other day.  Some doctors announced earlier this summer that they had "identified a group of 150 genetic variants that they said appeared to allow people to live past 100."  Very cool, but now it appears that there was a flaw with their test equipment.

Of course, I've never had that problem before....

The Power of Complaining, redux

Over two years ago I wrote about complaining to National Instruments and the eventual response from NI.  Well, back in March I wrote about what happened when I took the CLD.

I use Google Analytics periodically, so I know that my blog gets regular hits in the greater Austin area (National Instrument's home).  So I suppose I shouldn't be surprised that eventually someone from NI read about my test experience.  A few weeks ago I got an email from the Manager of Customer Education at NI to apologize for what happened.  She also said that the problems had been addressed and shouldn't happen again.

I'm not a NI or LabVIEW fanboy by any stretch, but I'll always acknowledge when they do something right.  Thank you, Carol.

How To Complain

Posting from Oregon

I haven’t posted in over a week since I took some vacation time, and then I was hit with a flurry of work that lasted until Saturday afternoon, took a quick break, and is going strong today.  A couple of days ago I was somewhere over west Texas watching electricity light up a thunderhead like a deranged Christmas tree.  So I decided to catch up on my reading.

What follows is a list of four articles from magazines, digests, etc that I subscribe to.  I managed to at least scan each of these and found them at least mildly interesting and at least somewhat related to test engineering.  Some of them are recent, some are over a year or so old.  I sometimes get delayed in my reading, but at least I get around to it.


Why We Need A Theory for Software Engineering
Dr Dobbs, Oct 2009
This is somewhat related to what I wrote a couple years back about software certification.  Plus it gets points for having Ivar Jacobson as an author.


Data Management Speeds Up Simulation of Crash Test Dummy Models
Nasa Tech Briefs June 2010
Crash test dummies are cool, and the idea of simulating those crashes and analyzing that simulated data is perversely cool as well.


The Online Shadow Economy
ZD Net/Messagelabs
This is a white paper, which means it is a piece of marketing with some small amount of redeeming tech value – the actual amount is negotiable.  I don’t know how real the picture painted by the author may be.  But it’s a fascinating one to examine, even if it is touched up with a bit of invisible ink.


Software Tool Integrating Data Flow Diagrams and Petri Nets
Nasa Tech Briefs March 2010
This little article intrigued me on several levels.  First, the tool itself looks like it would be useful for software testing (early in the process).  Second, I had never even heard of Petri Nets before - cool stuff.  And finally, the guy who invented them (at age thirteen no less) died just a couple weeks ago.

Blog anniversary follow-up

I was trolling around the NI website looking for blogs I may have overlooked when I wrote this post.  Then I found this little nugget: a recent presentation for NI employees about running blogs.  I had a good chuckle reading it, especially considering none of the NI blogs I saw were updated at the suggested once/week rate.  Also, several of the statements in that presentation paralleled a Wired article and NYT piece I covered a year ago.


When I worked at HP they had a policy of awarding money ($1000 back then) to anyone who was published in a magazine or journal.  So when I published an article in a visual basic magazine I scored twice: about a grand from the magazine as well as HP (sweet).  I wonder if NI employees that run their own blogs get extra compensation?  Or are they allowed to advertise on their blogs?  Food for thought.

Three year anniversary

I've now completed a third year of writing to this blog.  That's 133 posts, 35 of them over the past 12 months.  That's just a bit above my 32-post pace for year two, and way off my 66 posts the first year.  It's rough to keep up just a ~2.5 post/month pace, much less a post a week.

That's what I want to write about yet again today.  I took a look at the 8 blogs I had recommended after my first year.  Seven of them haven't been updated in a year or more, or only had a single post in the past several months.  I'm not even sure if the eighth blog counts, since it's maintained by Test and Measurement World.

I also tried looking at LabVIEW-specific blogs.  My main source was this list of blogs on the LabVIEW wiki.  Of that really long list, I only found 3 blogs that I would consider current: at least one post per month.  And ALL of those blogs are written by National Instruments employees, so again I'm not sure that counts.

So, aside from patting myself on the back, what am I saying?  I guess my point is that I've kept writing steadily for 3 years and intend to do it for years to come.  As I said a few days ago, I enjoy it.

Almost 3 years

As I mentioned back in April, I had several ideas for new posts but didn't have the time to finish them off.  Now it's close to the end of June and I've posted three items in the past week.  I'm catching up.

I am also approaching the 3rd year anniversary of this blog.  That date, along with my recent stops and starts, prompted me to ask, "Where am I going with this blog, and what do I want to accomplish?"

I occasionally use blog tracking software, so I know I get between 200 and 400 visits per month, averaging about 1.5 pages per visit.  That's a minuscule amount by popular blog scales, but test engineering is hardly a hot button topic.  People comment rarely, although I have had a few acquaintances tell me they read my blog and enjoyed it.

I don't get paid for this, it's not a supplement for my job, and I'm not trying to score points with people online.  Why do I do it?  Because a part of me always wanted to write - in college I briefly debated trying to become a novelist.  What do I want to accomplish?  To entertain and educate, in relatively equal proportions.

Okay, that's enough touchy-feely soul-searching for one day.  I hope everyone had a good weekend.

LabVIEW patent digging

I started down this path when I read an article about DASYLab in the April issue of Evaluation Engineering.  That triggered something in my memory about Measurement Computing, the company that published DASYLab.  After doing a little digging, I thought I confirmed what I remembered: National Instruments bought them out many years ago (1998).  But then I found a different article from 2003 stating that SoftWIRE, a subsidiary of MC, had patents it had acquired from Fluke that predate the NI patents for LV.  Hmm.  Finally, I found an article on Bloomberg that states, "as of April 29, 2005, Measurement Computing Corporation operates as a subsidiary of National Instruments Corporation."

But doing all that digging started me thinking about NI's patents.  Dataflow programming was first proposed way back in 1966 by Bert Sutherland, so NI couldn't patent that.  Although, if you do a patent search on, say, NI and programming you'll find hundreds of patents (or look here).  To my knowledge, patents can expire in as soon as twenty years.  LabVIEW was first introduced back in 1986.  Doing more digging, I found yet more nuggets:

• According to this news release, one of NI's key LabVIEW patents expires in April of next year.
• NI spent significant time and money defending a patent against The Mathworks (the MatLAB) people in 2002.
• There was a very interesting conversation on LAVA back in 2004 regarding the SoftWIRE v. NI lawsuit.
• Right around the turn of the century NI was in a LOT of activity: licensing patents and buying companies to resolve patent disputes (ex: here, here, over there, and out thatta way).

So where does this trip down the rabbit hole lead?  Here's what I saw:

1. Many of the original LabVIEW patents are getting long in the tooth and will start to expire as soon as next year, if they haven't already.
2. NI has no problems litigating patent infringement.
3. NI will buy companies to protect patents.

Based on that, here's my prediction: history will repeat itself.  In the next few years there will be at least one software company that develops a software package that competes on the cheap with LabVIEW (which currently runs several thousand dollars per license).  They'll be able to do this because of those expiring patents.  Heck, they may even write their compiler so that it can use subVIs written for LabVIEW.  After this happens, NI will sue them, force them out of business, or buy them.  I imagine they'll buy them out - I doubt they'd want the price point on LabVIEW to drop at all.

It'll be interesting to see how it plays out.

SQL Options

There is a great article on non-SQL databases in the June issue of  Dr. Dobb's Digest.  It basically surveys the NoSQL movement, something that I quite frankly had no idea existed before I read about it this past weekend: non-relational databases designed to handle terrabytes of data across multiple geographically divers systems.  I'm far from a database expert, but I've dealt with them enough so that I could follow the article.

I'm bringing this up today because it dovetails in with a post I wrote almost a year ago.  The point I was making back then was that, with memory and computing so cheap, large amounts of data and statistics would become an increasingly larger part of a test engineer's job.  The Dr. Dobb's article complements this idea by describing the tools being developed to deal with this data.

Test Engineer Bucket List

I've never seen the movie The Bucket List.  Nor have I seen either the MTV show or the CBS special that played on the same idea.  The idea of making a list of things to do has certainly been around for a while.  In fact, a good friend of mine crossed off a major item on his list a few years ago when he bought a Ferrari.  "I could almost die happy now," he said.

When he first took me for a spin in his sweet ride, I started thinking about my own list.  But now I'm putting a different spin on it: a test engineer bucket list.  Before I retire, hopefully a long time from now, what would I like to do as an engineer?

I'm not talking about accomplishments.  It would be quite easy to make a list that included items like, "make a ton of money, receive multiple patents, publish numerous papers."  That's more of a self-serving list than a self-fulfilling list.  Instead, I aimed for things that I would personally want to do as a test engineer, things that I would find professionally satisfying, and things that are just fun. Often we don't think of work as "fun," but sometimes it can be a real hoot.

So I came up with a list of five items.  They're in no particular order, but I think they all fit my above boundary conditions.  Perhaps it will inspire someone to create their own list.


Mentor a young engineer
I don't think I'm quite old enough to seriously consider being the "elder voice of experience" for younger test engineers.  But I can think of several people who tutored me when I was younger.  Those lessons were not really about technical details.  They had to do more with how to deal with difficult coworkers, presenting your case in a meeting, and other things you don't get in college classes.  I'd like to pass on the favor at some point down the line.

Work as a true manufacturing test engineer
Most of my career has been on the R&D side, bringing up a pilot production system, or small production quantities.  I think it would be interesting to see how the other side lives: analyzing massive amounts of data for a thousand devices tested a week, troubleshooting an entire floor of test systems.  Maybe I'd do it for a few months, maybe a few years.

Be a consultant
This is similar to the "manufacturing test engineer" item above.  I worked in sales for a couple years, and that scratched a particular itch.  Trying out my hand as an engineering consultant would be another one of those itches.  I've worked with several consultants, and sometimes I've thought it would be fun to try that career change out for a while.

Develop a test system that measures a fundamental aspect of the universe
I used to do this, a long time ago.  Over the past decade I've worked at startup companies trying to commercialize bleeding edge technology, and that has it's moments.  But nothing beats the thrill of measuring something that stretches the bounds of science itself.  It'd be great to experience that once more.

Write a story about a test engineer
This would definitely be on the "fun" list.  I don't think I've ever read a novel about an intrepid test engineer braving impossible odds to save the day.  I do think it would be a blast to try and write one.

Getting busy again

It's getting pretty busy again for me, in my work and personal life.  Because of that, I have several post ideas awaiting completion, ranging from "mostly written" to "a couple of web links."  At any rate, by the end of June I expect to have them all done.  In no particular order, here's a list of what I have in mind:

• Updating the blog
• LabVIEW 2010 testing
• ATML
• Bucket lists
• LabVIEW patents
• Reliability testing

LHC!!

Over the past couple years I've talked about my history with high energy physics (HEP) and my excitement with the LHC (here or here, for example).  Well, on March 30th they finally slammed protons together at a total energy of 7TeV.  Granted, that's only half the energy total they're aiming for, but at least it's doing real physics now.

Looking for evidence of the Higgs boson (that's suppose to be the particle that explains mass like photons do for light) or dark matter is supposedly the official reason for the LHC.  But there's always a perverse side of HEP that wants to break the Standard Model.  If you can't find the Higgs, or you find something completely different, then that's when it gets really interesting.  Sometimes I miss being in the mix of that, but life goes on.

If you're interested, there's lots of photos, videos, and other goodies at the public CERN website.

April Fools Day - Klingon Tests

Back a couple months ago I posted a couple of bad jokes I had made up about hydrogen.  Since then I've been thinking about posting more jokes, but in a testing vein.  I've done that before (here and here), and April Fools' Day seems like a good time to do it again.

If you hate Star Trek, you might want to stop now.  You won't really get it.
======================


Okay, what I'm posting below is actually a repeat of some jokes I had on my group's website when I worked at HP.  Enjoy.

• Specifications are for the weak and timid!
• You question the worthiness of my code? I should kill you where you stand!
• Indentation?! - I will show you how to indent when I indent your skull!
• What is this talk of 'release'? Klingons do not make software releases. Our software escapes, leaving a bloody trail of designers and QA testers in its wake.
• Klingon function calls do not have 'parameters' - they have 'arguments' - and they ALWAYS WIN THEM.
• Debugging? Klingons do not debug. Our software does not coddle the weak.
• A TRUE Klingon Warrior does not comment on his code!
• Klingon software does NOT have BUGS. It has FEATURES, and those features are too sophisticated for a Romulan pig like you to understand.
• You cannot truly appreciate Dilbert unless you have read it in the original Klingon.
• Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!

As a bonus feature, a friend of mine from high school forwarded these old Star Trek images to me.  Enjoy.

Falling into your lap

Sometimes a perfect project just falls in your lap.

At work I've been heavy into upgrading an existing test system, but I'm at that point in a project where I can see the end.  I was starting to consider what I should work on next.  I'm not at a loss of potential ideas, but none of them seemed very urgent.  Then one of the R&D engineers came to me with a need to do some visual inspection measurements.  That sounded great to me, because it's been three years and two companies ago since I last worked with the LabVIEW vision tools.  This should be fun.

Passed the CLD (part 5) - test day

I passed the CLD exam a couple weeks ago, and I'm writing about that experience.  I've talked about the NI courses, working sample problems, and my test prep guide.  So all that's left is to go over the actual experience.  The description is a bit personal, but hopefully if you take the test yourself you might get something out of this account.

It's been a long time since I took a serious test.  The last time must be when I took CS grad school classes back in the late 90s.  I was nervous.  To fight that feeling, I tried to prepare myself as well as I could.  Get plenty of sleep for about two days prior to the test, jam to good music the night before, eat a good breakfast that morning.  I drove down late Monday morning for the 10am appointment.

I brought my own mug in with me to the test, filled with Mountain Dew (an old college habit).  I took the exam in a nice quiet room at a nearby NI office.  Unfortunately, this nice quiet room was right next door to the breakroom.  At noon it got very noisy.  The NI employees were having a good time discussing their weekends.  They must have enjoyed it, because there was a lot of loud laughing.

Around 1pm, after trying to code through an hour of conversation, LabVIEW crashed.  Great.  Fortunately, I had the sense enough to leave the computer alone and show the coordinator what happened.  She called down to NI in Austin, and they gave me the option of getting some extra test time or retaking the test another day.  Tough call, but I decided to just finish the thing.  So I rebooted the computer, restarted LV, recovered the code, figured out what work I had lost, and got back into the programming zone (thankfully quiet this time around).

So that's what my test day was like.  It could have been worse, but if any of you take the exam I hope your day is better than mine.

Passed the CLD (part 4) - preparations

I passed the CLD exam a couple weeks ago, and I'm writing about that experience.  I've talked about the NI courses  and the NI sample problems.  Now I want to show you my test prep guide.

Before I copy it down, let me describe it.  I had two goals.  First, I suspected that the 4 hour limit would be tough for me, so I wanted to lay out what I should be doing and when.  Second, I researched the test extensively.  Aside from reading the NI-provided preparation materials, I read online articles and what people wrote about it (for example, on the NI forums or at LAVA).  I wanted to efficiently summarize that information.

So, here it is.  If you copy it to a two-column document, it fits on a single piece of paper.

1.       Open LV if not already open.

2.       Read through the problem.

3.       Create a blank project and save it.

4.       Ctrl-H so I can see the help box.

a.       Reminds me to comment everything.

5.       Create a blank VI.

a.       Turn off automatic tool selection.

b.       Select nothing on the front panel and change the font style to bold.  This makes all subsequent creations boldface.

c.        In the block diagram, open the function palette and search for something.

                                                               i.      It takes time for the list to populate.

d.       Click on the icon to change it.

                                                               i.      It takes time to load the icon editor.

6.       Read through the problem again, in detail.

a.       Define the basic objects.

                                                               i.      These will likely be custom controls.

                                                              ii.      Start creating some base objects.

1.       Reference the GUI.

b.       Define what the different state conditions are.

                                                               i.      The graders look for a state machine, event structure with states, etc.  Looking for specific states is a good place to start.

c.        Decide on the basic architecture to use.  NI states that “exams are based on a sequencer-type application” and “timing is an essential aspect.”

                                                               i.      State machines: obvious solution, but not suited for storing sequences or (maybe) GUI events.

                                                              ii.      Queue-based events: commonly used, stores sequences, limit the processing in the event case.

                                                            iii.      Producer-consumer: possible choice for some CLDs, not great for non-user interface events.

d.       Timing

                                                               i.      Execution: Regulates loop execution (ie – state machine) – may introduce jitter or unresponsiveness.

                                                              ii.      Software: Measures elapsed time with stop/reset/pause options.  Use func global, subVI, or express VI.

                                                            iii.      Others: Event case timeout, synch VI timeout.

e.        Create a top-level VI using a design pattern.  Probably a state machine, producer-consumer, or something like that depending on the problem.

                                                               i.      Take up the full screen width so you know your space – shrink it later.

f.        Save it and verify it’s added to the project.

7.       From the provided screen shot, design the basics of the front panel.

8.       Style checklist

a.       Avoid local variables.

b.       Property nodes <> indicator or control values.

c.        Type defs!

d.       No coercions or default tunnels.

e.        Make subVIs.

f.        Readable code!

9.       Error handling

a.       Wire error terminals.

b.       Wire error clusters to “no error” case.

c.        Stop top level VI on error (all loops)!

d.       Use simple error handler on program exit.

e.        Monitor errors from parallel loops.

10.    Documentation

a.       Documentation for the VI & subVIs.

b.       Free labels on wires.

c.        Labels on block diagram items.

d.       Label the actual loops (yes you can).

e.        Label constants.

f.        Tip strips on GUI.

g.        Consistent icon scheme.

h.       Be brief & to the point.

11.    Test

a.       Functionality

b.       Weird behavior from user.

12.    Final check through.

a.       Close the project.

b.       Reopen it.

c.        Open the top level. 

                                                               i.      Make sure there are no errors.

                                                              ii.      Verify that it runs correctly.

d.       Double check documentation on every VI.

e.        Make important terminals on subVIs required.

f.        Run VI Analyzer if time permits.

===========================

I'll have just one more posts on this subject: the actual test day experience.  That should be up in a couple of days, and then on to other topics.