- Front Panel: Connector pane terminals default to Required: CHECKED - I really love this option, which was added in LabVIEW 8.5. There were so many times in the past when I was working on an app, and I'd add inputs to a subVI but forget to wire them up in the calling VI, then spend several minutes debugging before I figured out what I'd done. Also, this option is smart enough to ignore error input terminals, leaving them as Recommended.
- Block Diagram: Enable automatic error handling in new VIs: UNCHECKED - I understand that this option exists for the benefit of new LabVIEW users, but for the rest of us, it's just WRONG.
- Block Diagram: Enable automatic wire routing: UNCHECKED - I've tried this option a few times, but I think my manual routing of wires produces much cleaner diagrams.
- Block Diagram: Enable auto wiring: CHECKED - I remember when I worked in the AE department and hadn't yet joined LabVIEW R&D, I attended a "demo day" on the LabVIEW floor where all the LabVIEW developers were showing off the features they were working on. When I saw this one (called "wire kissing" at the time), I thought it was way cool. And I've been a fan ever since, especially for automatically wiring error clusters. Note that when you drop objects with Super Quick Drop, auto wiring does not occur...but it's a small price to pay in order to be able to code at lightning speed...
- Front Panel/Block Diagram: Labels snap to preset positions on terminals: CHECKED - Another one of my favorites...this one was under my radar until it just appeared one day in a build of LabVIEW 8.0. My boss is a bigtime pixel-counter, so it was nice to have a really quick way to drag a label into the correct spot.
- Block Diagram: Place front panel terminals as icons: UNCHECKED - In LabVIEW R&D there is one extremely fierce advocate of keeping this feature checked by default. He shall remain nameless. If he wasn't around, though, we probably would have changed this option long ago (I'd personally prefer that we just remove it altogether). Looking at the big picture, though, it's probably worth having this option checked by default and keeping this guy around. :)
- Block Diagram: Place structures with Auto Grow enabled: UNCHECKED - I take pride in the way my diagrams look, and I like having 100% control over how they look. The thought of dropping a function in a nested structure, and having a bunch of crap all over the diagram move around as a result...it's a little too much for me to take.
- Block Diagram: Show red Xs on broken wires: UNCHECKED - Originally this feature did not have an entry in Tools > Options...you either lived with it, or found out what the INI token was to disable it. I hated the feature so much, I demanded a Tools > Options checkbox. What I didn't know was that, at the time (LabVIEW 7.0), the Block Diagram page in Tools > Options was completely full, and required a complete reorganization to fit in this new option. You should have seen the sad look on the unnamed developer's face (yes, the same one who likes terminal icons) when he realized that he was going to have to add my option. For those of you who hate red Xs, you're welcome.
- Block Diagram: Show dots at wire junctions: UNCHECKED - I just think they're ugly.
- Block Diagram: Show constant folding of wires/structures: UNCHECKED - The fuzzy wires make my eyes hurt. And I never really saw any benefit to knowing when constant folding is taking place. Seemed like more of a novelty than a utility.
- Block Diagram: Auto-insert Feedback Node in cycles: UNCHECKED - Don't get me wrong, I really like Feedback Nodes as a replacement for Functional Globals. But every once in a while I'd be wiring up some stuff in a loop, and connecting wires to each other while re-wiring things, and somehow my broken wires would turn into Feedback Nodes, and that freaked me out. So now I only get Feedback Nodes if I explicitly drop them myself.
- Alignment Grid: Everything: UNCHECKED - I don't like the grid. It makes things look too noisy.
- Controls/Functions Palettes: Palette Loading: LOAD PALETTES DURING LAUNCH - As you hopefully know by now, this enables Quick Drop to be instantly usable on its first use, at the expense of a slightly longer LabVIEW launch time.
- Environment: Maximum undo steps per VI: 99 - I've never seen any performance problems with cranking up this setting.
- Environment: Skip Getting Started window on launch: CHECKED - Since my LabVIEW launch time is a little longer for Quick Drop, I figure I can save a second or so if I don't have to load the GSW...I never really used it for anything special that I couldn't access from a new VI's File menu.
- Environment: Lock automatic tool selection: UNCHECKED - I'm a big fan of the Auto Tool, but I do like being able to press Tab, like the good ol' days, if I really need to.
Tuesday, February 24, 2009
I've seen many people (myself included) make vocal arguments in favor of their own personal Tools > Options settings. Ultimately though, most of these settings come down to personal taste. Here now, are my personal preferences regarding many frequently-discussed Tools > Options settings, along with an occasional anecdote. Keep in mind that you can simply copy your LabVIEW.ini file from one LabVIEW installation to another to preserve these settings (so you don't have to go through and check/uncheck a bunch of options with every new LabVIEW install):
Sunday, February 8, 2009
NOTE: As of July 2010, the CLA Exam has changed, rendering most of the information in this blog post obsolete. For more information about the changes, see my Changes to the CLA Exam post.
When I embarked on the LabVIEW Certification journey, I knew I was going to go all the way. So after I passed the CLD, I immediately began preparing for the Certified LabVIEW Architect (CLA) Exam. According to the CLA webpage, there are several areas of competence associated with the exam, including "mastery in architecting LabVIEW applications", "effectively utilizing project and configuration management tools", and "experience of approximately 24 months in developing medium to large LabVIEW applications".
One of the things I discovered almost immediately was the simple lack of CLA preparation materials. The CLAD had the webcast, the prep guide, the LabVIEW Fundamentals Exam and at least one practice exam that I could find. The CLD had the webcast, the prep guide, and three practice exams. The CLA, however, had no practice exams available. In fact, the only preparation material available on the NI website is the CLA Exam Preparation Guide. I highly recommend reading this preparation guide, as it is the only available "official" source of information on the exam. Also, after taking the exam, I now understand why there isn't much in the way of preparation materials...more on that later.
So once I read the CLA prep guide, I knew the test would consist of a written component worth 40% and a coding component worth 60%. The written component of the test consists of short-answer questions pertaining to project planning, and the coding component consists of developing an architecture for the actual application.
Now one of the other things mentioned in the CLA prep guide was that the LabVIEW Advanced course offered by NI covers a lot of the material tested on the CLA. Since I work for NI, it was easy for me to get my hands on a copy of the LabVIEW Advanced course and check it out. Sure enough, it covered a lot of the topics listed in the CLA prep guide. I don't think reading through this course was a crucial step in my passing the CLA, but it certainly didn't hurt.
Honestly, the best preparation I did for the CLA was the simple act of being a full-time LabVIEW developer for the past seven years. Topics like writing specification documents, source code control, and designing architectures have simply been part of my job. If you have been part of a multi-developer LabVIEW team for any length of time, then a lot of the topics in the CLA exam should come naturally to you. If you're brand new to LabVIEW, or if you've only been developing small-scale applications, or if you've been flying solo without a formal software design process, this certification may not be for you. There's not really any way to "practice" these sorts of things right before the test, which is why it makes sense to me (now) that there isn't much prep material available. Nevertheless, I offer the following tips for anyone attempting the CLA. These come from my own personal experiences in preparing for and taking the exam:
- Since the written component of the CLA is worth 40% of your grade, and the coding component is worth 60%, I recommend spending your time in a similar proportion. My personal times ended up being 1.5 hours on the written and 2.5 hours on the coding.
- For the written component of the exam, many of the questions ask for a certain number of short responses, i.e. "Give 3 problems you might encounter if...". For these, I recommend a bulleted list of one sentence (or maybe two) for each answer. Keep the answers concise. Writing a paragraph for an answer that could be written in a sentence doesn't get you any extra points, and only wastes precious time (and for me, time was very precious...see below).
- In the coding component of the exam, you should pretty much follow the same guidelines you followed when writing the code for your CLD exam (see here for my advice on the CLD). Document your code, use good style, know your design patterns, etc. etc. Obviously you probably won't have as much time to do things like document every front panel control of every VI you write, but do the best you can given the time you have.
- Speaking of time, here is the most important advice I have to offer. Unlike the CLD (which I finished in 2.5 hours), I was severely time-crunched on the CLA. To give you an idea how time-crunched I was, I realized when I had 45 minutes left that I still had about 2 hours worth of coding to do. Oops! It turns out that I did not heed the advice given in the CLA prep guide, which was that I was not supposed to write a fully-functional application! This is very, very good advice. The application specifications given in the CLA for a functional application would be relatively easy for me to complete...in about 6 hours. Unfortunately, I had 2.5 hours to write code for the CLA. And as I so often do when I write LabVIEW code, I got into "the zone", where I started writing lots of subVIs to implement specific, non-essential details of the application, before I had fully completed the overall architecture. When you take the CLA, do not do this! Focus on the architectural patterns, focus on the design for your plugins, focus on the data sharing mechanisms you use, but do not just start fully implementing non-essential subVIs! For example, I spent about 30 minutes writing a nifty little algorithm for part of my plug-in architecture. This was a bad idea. What I *should* have done was write the interface for the VI (i.e. the conpane and typedefs), and included a 1-2 sentence comment on the diagram describing how the algorithm would work. Now thankfully, I'm a pretty fast coder, so once I realized I was running out of time, I kicked it into hyperdrive and got some code written that (apparently) was passable. But I wouldn't wish that 45 minutes worth of monumental stress on anybody! Not even a text-based programmer!