01 July 2014
tags: linux-kernel labview
As of a month or so ago I was still going strong with the Eudyptula
Challenge tasks: building development kernels, hacking on dynamically
loadable modules, exploring intricacies of git, and generally learning
my way around the internal structures that make Linux tick.
I had just begun to really dig into the whole idea of concurrency and
the mechanisms (locking and so forth) and race condition caveats the
kernel and its documentation have to offer. Then something came up.
Cutscene with BBQ
Our local National Instruments LabVIEW User Group runs a pretty tight
ship. I haven't used LabVIEW itself much (I have messed around with
it quite a bit), but the test equipment I've been working with for
the past couple of years runs on LabWindows/CVI -- NI's C environment
("C with training wheels", a coworker of mine likes to say). So I'm
not especially proficient in LabVIEW, but I do attend the user group
meetings: There's usually a fairly interesting demonstration of its
features or of some real-world deployment. The whole concept of dataflow
programming is interesting to me for a few reasons, too, related in part
to my longtime interest in audio processing -- cf. Pure Data, Max, even
(going back a few extra years) Turbosynth.
And I'd be lying if I told you the free barbecue they brought into the
meetings wasn't a factor.
Last year the user group offered its regular attendees the chance to
take NI's CLAD certification exam at no cost. It took a little bit of
study, but the CLAD is their entry-level certification. The exam is
fairly basic, and I passed without much difficulty.
If you're not familiar with LabVIEW, it's pretty neat stuff. It's
a full-featured high-level language, but the development interface
is based on the concept of dataflow . That is, instead of writing
text-based code, you connect functional blocks together with graphical
"wires". It is used extensively in a number of industries, particularly
in testing and industrial data-aquisition applications. If you're just a
curious amateur the software isn't cheap, but if (like me) you work in
an environment where it is available, it's worth checking out.
Would You Like an Exam with That?
This spring they offered a similar opportunity, but for people who
aready have the CLAD certification they offered the CLD exam -- their
full professional development certification.
Great, I thought -- not a chance I should pass up. It normally costs
about $400. But ... the CLD is a far more challenging exam. It's geared
not only to proficiency, but to facility with the software and its
graphical language.
It's a 4-hour practical exam. They shut you in a room, give you
a sealed spec for an application of nontrivial complexity (typical
textbook state machines -- modelling behavior of systems like ATMs,
vending machines, and so forth -- but with a lot of real-world-like
functions, constraints, and corner cases). Without any external
references or breaks, you have to build a working application.
Four hours may seem like a long time, but it's widely regarded as the
most challenging aspect of the CLD exam. To implement the typically
specified complexity in the time allotted, you really have to know
your way around the software and be able to make quick decisions about
how to implement the application's logic.
There's not any wiggle room. You can't take breaks or use your phone. No
Internet or reference manual is available (other than LabVIEW's built-in
help). When time runs out, you save your code to a thumb drive, seal it
in an envelope, and wait several weeks for an anonymous NI engineer to
review your code. To fast-forward a bit: I took the exam back in May, and
still haven't received my results.
Cram Time
As I mentioned, I haven't really used LabVIEW that much. When I heard that I
could take the CLD exam for free, and that I only had a few weeks to prepare...
I did a quick deep-dive into some LabVIEW books, familiarizing myself with some
of the conventions and best practices for more intricate applications (things
like event-driven logic, queued state machines, and producer-consumer
frameworks, among others).
I learned a ton, but I would be shocked if I passed. That is really OK
-- getting the certification would have been lovely, but the experience
of preparing for and taking the exam were my primary goals. I got a
whole lot out of it, not only in that little bout of self-training, but the
exam itself was pretty eye-opening, too. Not only will I be far better
prepared to approach the exam next time it is offered, but it has given
me some ideas for things I could do with LabVIEW in the meantime.
Back to the Penguin
Of course, through all of that, my kernel-coding efforts were on hold.
Since the CLD exam, I've spent the last few weeks refamiliarizing myself
with the Eudyptula Challenge task I was on when I set it down. It took
less time than I feared to find my bearings; I had been in the middle of
Task 8, and submitted it just the other day. From what I understand, it
takes about a week for Little to respond to that one (one of the more
complex tasks), so I'm using the downtime to run through kernel-build
processes again, as that's a skill that tends to languish when I don't
use it regularly, and it's been a while. I have a feeling I'll be using
it again soon.