Leaderboard

So I posted my ealier frustrations with the CLA Exam in Nom, Nom, Nom..., and since I recently presented at a user group meeting I was given the opportunity to take the exam again on the 19th. I'd been so busy I haven't had any time to practice but I figured I might as well. The second exam problem was very similar to the first, but I think a few requirements had been removed. My impression was that it had been simplified a bit. The first time around I worked on the api's for each major component and tried to get them connected together via messaging. None of the components were fully implemented. I had developed the messaging structure and tried to make sure the mediator loops (that handle message routing) were routing messages to their correct destinations. Honestly though, I don't remember how complete that part of the app was. At the time I felt like I had developed a reasonably good framework that could be filled in by CLDs who understood the framework. As I detailed in Nom, Nom, Nom..., NI disagreed. One piece of feedback I received from NI while reviewing the first exam was to implement one component completely so developers could use it as an implementation example for the other components I design. I did that this time around, but it took so much time I didn't do any work on several modules and the top end component tying all the pieces together wasn't fleshed out at all. When I finished the exam my solution felt far less complete than my solution for the first exam. There were many [Covers: xxx] tags I didn't get around to working on. I left with no expectations whatsoever and figured I'll keep presenting and keep retaking the exam until they take pity on me or just get tired of seeing my name. To prove truth is stranger than fiction, I passed. I am honestly just as surprised I passed this time as I was that I failed the first time. The overall structure of my app was the same this time around as the first time--components executing in parallel communicating via hierarchical messaging and Harel/UML style state machines as needed. I think I used class-based state machines the first time whereas this time I used a flat state machine contained on a single block diagram. That might have made it easier to understand but IMO is an implementation detail not terribly important to the overall architecture. I'm not complaining about passing but I have to say I still don't understand NI's grading system at all. Here's my scoring breakdown with evaluation comments in parentheses: Style: 10/10 Documentation: 16/20 (Architecture/modules not documented adequately for developer to implement/complete functionality.) Req Coverage: 18/30 (Percentage of requirements covered = 60%.) Arch Development: 30/40 (Comments had 4 different "xxx module not designed.") Baffled... (See y'all at the arch summit! )

Well you are right that Flatten Variant doesn't work. I was mislead by a quick trial and had no time to verify further as I had to leave for private obligations. However I can't accept defeat so I remembered another post where someone wanted to have an VT_NULL Variant and investigating into the solution I have come up then showed an easy and totally official way to do it. The VARIANT memory layout is fully documented on MSDN and the LabVIEW Call Library Node supports explicitly the ActiveX Variant type. So simply passing the Variant as ActiveX Variant pointer to a C function that looks at the first two bytes in the structure is all that is needed to get at the VT_ values. Enclosed are the VI to create specifically a VT_NULL variant and the VI to read the VT_ type. I haven't entered the entire range of VT codes into the enum and since those codes are in fact not continous it is probably better to use a Ring control instead but that is an exercise left for whomever is wanting to use this VI. Get OLE Variant Type.vi NULL Variant.vi

Let me add my 0,05 Euro As a non-native speaker (German) it certainly is a bit more challenging, but (with a tight margin) I did it. I am an official Certified Labview Architect. For all others benefit let me give you a few comments. If you come from CLD (well, we all do) where style is a major issue, look at the requirements as posted before. The time is definitly too short to present a sound design. But I guess thats meant to be. You'll surely end up with white spots in your design. Be wise were to leave these. Write a lot. Explain, what you want to do. Build a top level VI with startup and shut down, even with, maybe, blank frames. Write for each of the modules a VI with all connections and put your [Covers: xxx] at least there. Define typedefs there, they'll be needed otherwhere. For all state machines make frames as required and again place your "Covers" there. Then again check your comments. Then start with a simple object and complete it as much as possible. No need to go to "advanced stuff" like classes or Xctrl. I did, a colleague of mine did not. We both passed. So again, architecture is at the top. Start from the top! Good luck Gabi

Well, since this is kind of the "Don't use classes in your CLA exam solution" thread, I figured I'd chime in with my $0.02 CDN now that I've passed... I spent a long time thinking about whether I'd use classes going in to the exam. I received strong advice from a few people not to, but also bought into Steven's statements above about his experience. In the end, I decided to go with classes for 2 reasons: Firstly, because I'm now way more comfortable using them than not using them (and I hate the sample exam solution's use of "action engine"-type VIs, with tons of non-required inputs), and secondly on principle - Architects should use classes, and if the examination mechanism can't handle that then it needs to be challenged. My use of classes was quite straightforward, and seemed obvious (to me at least). All of my VIs and controls belonged to a class except my top level VI. The only issues the markers took with my architecture were to note the areas where it wasn't complete or properly documented, which was completely fair (since it wasn't - I ran out of time). I'd say my biggest mistake was getting sucked into too much "implementation", at the expense of completing the architecture. I am certainly grateful for this thread though, since it raised the level of discourse about this issue before I wrote my exam, and Zaki spent a lot of time addressing this in the exam prep session I attended. I would say, however, that using classes probably takes more time. There's a lot of "background" work to creating a good class hierarchy, with icons, documentation, data member access VIs, access scope, etc. If you're confident in your ability to create a non-OOP solution, you might consider this. Time was a huge factor for me, and four hours of hard-core, non-stop LabVIEWery is exhausting. And here's a tip I struck upon the night before my exam: Create a quick-drop plugin to prompt you for a requirement ID and automatically create a "[Covers: XX]" free label. This only took me about a minute (I memorized the steps before the exam), and probably saved me 20. Make sure you turn on scripting in Tools-Options, then copy "C:\Program Files\National Instruments\LabVIEW 2010\resource\dialog\QuickDrop\QuickDrop Plugin Template.vi" into the "plugins" folder, rename it, and edit it to create a Text decoration with the appropriate text. You can even use the "Prompt User for Input" Express VI . Then assign an unused key (hit Ctrl-Space, click on "Shortcuts...", then the "Ctrl-Key Shortcuts" tab, and your VI should show up in the list). For me, adding a "Covers:" free label was only a few key-clicks. Jaegen