I obtained the CLED (Certified LabVIEW Embedded Developer) certification last week. A good friend said that the world didn’t need to know that I had to take the practical exam twice. I decided to make it public here to add credibility when I say I know what works and what does not work, at least for me. I hope this helps you, and saves you the extra test 😉

The CLED exam has two parts:

  • A multiple choice exam (or like I like to call it, “a multiple confusion” exam)
  • A five-hour practical exam

The best way to prepare for the multiple choice part is to be very familiar with the cRIO Developer’s guide. You can download the entire guide as a pdf at the lower right corner of that page.

I will focus on how to prepare for the practical exam.

As some of you know, I have coached a lot of people on how to prepare for the CLD and CLA exams. The first thing I ask candidates is to understand what is their current proficiency level and how they code in their daily life. Next, we work on figuring out what good practices need to be set aside and which ones need to be embraced for the exam. I also help them come up with the best strategy for them. In order to pass the exam, a lot of focus needs to be put on time management and aiming for the highest amount of points. Unlike your daily work, where I expect you focus on quality as your most important requirement, the exam requires a different mindset. For those taking the CLD exam, the goal is to have a running application at the end of the exam. If you have a broken arrow,  you will likely fail. For CLA candidates, I tell them they need to focus on covering all of the requirements without spending too much time wiring code. If you have a running application at the end of the test, you will likely fail because you probably spent your time coding instead of architecting.

The CLED is more like the CLD in the sense that your goal is a running application at the end of the test, but it is more like the CLA in scope. There are lot more requirements to cover in the CLED, and although NI has been kind enough to allow for five hours, it is still not enough time to implement all of the requirements.

Here are Fab’s tips to prepare for the CLED practical exam:

1. Focus on getting a running application within the first 30 minutes of the exam

The CLED test requires running code on three levels:

  • A host VI running on the desktop
  • A Real Time VI running on the target

Make sure you are able to write a complete architecture for these three levels, and be able to troubleshoot any connection issues between them. What didn’t work out for me the first time is that I practiced creating this architecture from scratch, because I had read/heard in multiple places that we should not try to use the shipping sample project templates. Well, this was not the right approach for me. As you know, I am big advocate for not reinventing the wheel, and starting with architecture that launches when you tell it to launch, has error handling and stops when you tell it to stop. This is one of the reasons we created DQMH! This means that I am very rusty in creating something from scratch. I ended up making the same mistakes that I have solved in the past.  This took a long time and I didn’t have time to troubleshoot communication between my different layers. I also was not very familiar with the shipping sample project templates. My complaint regarding the sample project templates for LabVIEW RT and FPGA is that they are not Project Templates, they are sample projects. If you look at the desktop templates, we have the NI QMH project template that is used to implement the Data logging sample project template. The NI QMH project template does not attempt to implement a full blown application, but it includes the things that we would normally want to have in an application: it launches when we tell it to launch, has error handling and it stops when we tell it to stop. I would not start a new project from the sample project. I see the sample project template as way to understand how the template can be used. Well, LabVIEW RT and FPGA lack these project templates. For the second time around, I became familiar with both sample project templates, understood how they are implemented, and identified their shortcomings. I also practiced modifying them to get them to work with a new target and get to that running application within the first 30 minutes. This meant that early on the day of the exam I was more confident and my goal from then on was to make sure that at the end of each hour I had a running application at the desktop, RT and FPGA levels.

2. Set a deadline for your last FPGA compile

The sample CLED exam does not include too much code in the FPGA. For the first exam, I set an unrealistic goal of not compiling more than three times. To my surprise, I ended up having to include a lot more code in the FPGA than what I anticipated. The issue was that I did not adjust my strategy accordingly, and still tried to minimize the number of times I compiled the code. This was definitely not the right approach. The second time, I had a more realistic goal of not doing FPGA compiles during the last hour of the exam. Whatever I had at the end of the fourth hour would be what I would deliver as my final solution. This approach ensures you don’t risk breaking everything at the last minute, which brings me to tip number 3.

3. Use version control

No, you won’t be able to use SVN, Hg, Git or whatever professional source code control tool you use at work (if you don’t use version control, stop reading and go to see my post on source code control!). Remember I told you there were going to be some good practices that you would have to leave at the door and others that you would have to embrace. Well, the part you leave at the door is using a professional tool, and what you bring with you into the room is having a strategy for version control. Mine is to create a build specification on my project for a zip file, or just zip the entire folder where I was coding my solution.  Make sure you have all your dependencies in the project, including your FPGA bitfile and check on the items view of your project that everything you are calling is under the folder you are using! At the end of each hour, or when I had achieved the goal of having the full application from host UI to FPGA running, I would build a zip file. This meant that if at any point everything came falling down, I could always go to my last zip file version and deliver that as my exam solution. I did not need to do this at any point, but just knowing it was there, gave me peace of mind.  I would not recommend this approach in real life (use real source code control there!), but this is a test, not real life.

4. Be prepared to code towards a black box

I did not realize how much I rely on having LEDs, buttons, function generators, multimeters, scopes, etc. when I am working on an embedded application until I did not have access to any of these things. I mean, those things are either around or are part of the NI Evaluation board that I used to prepare for the exam. Even if I do not use these things, I rely on what I observe the hardware is doing. I even asked a friend to loan me his Eval board so I could practice coding the controller and running the simulated plant on his evaluation board (btw, the simulated plant had some errors and I did have to change some of the wiring for it to work, let me know in the comments if you want me to share the changes I made). Well, the day of the exam I realized the hardware is in a box with a plexiglass cover. There are no LEDs, no buttons, and no wires to probe. You cannot even access the reset button! Also, the plant doesn’t have a GUI. This threw me off more than I expected. The second time around I knew what to expect. I knew I was not going to see what the plant was doing until I had things coded. This time I did not panic and I made sure I could see the signals I was interested in and I could put out the control signals I needed to generate. Doing this early on meant I could get an idea of what the hardware was doing.

5. You will not be able to implement every single requirement

I am a perfectionist and for too long I have been using test driven development and making sure my code works well and implements all the features needed every step of the way. I definitely needed to leave that at the door. The first time around, after the shock of how much code I was going to need in the FPGA, I spent too much time on getting the FPGA to work. Then I moved to the RT level, and then I went to the GUI. This was a terrible mistake, because I ended up not having enough time on the GUI, and my application didn’t run at the end of the test. Well, the GUI ran, the RT ran and the FPGA code ran, but the GUI could not connect to the target!! Basic, right? Go back to tip number 1 and see why it is tip number 1. The second time around, I took more an approach of implementing each feature all the way from the FPGA to the GUI, making sure that at the end of each implementation, I had a running application. If I was not sure about something, I would just leave a bookmark to remind me to come back and check it later. I added extra buttons and indicators to the FPGA that I would normally not add, so I could have a way to simulate a requirement that was not completely implemented.

What is that?

You want to know my grade?

Well, the first time around I was very close to the passing grade of 70. The second time around I was aiming for a 74, because I thought anything else was vanity… well, all I can tell you is that I was very happy with all that extra vanity I got! 🙂

I hope this helps and if you want more assistance, feel free to contact us and we can setup some coaching sessions to get you ready for your certification exams.

Happy wiring!,