SteveChandler

Is it specific to the combo box? What do you see when you put a probe on the string array wire? Also have you tried temporarily changing the wait 0mS to wait longer? Since it works with highlight execution I would suspect that in normal run the device has not responded yet where you are checking the number of bytes at serial port. If the device has not responded yet it will return zero.

If waiting longer fixes it then that is not the best fix. It just tells you where the problem is. The best thing would be to use some kind of handshaking. Does your device send a termination character? Does it send a fixed length reply? If not then it gets a little bit more tricky. One solution in that case would be to loop until bytes at serial port is not zero. Be careful with that because that loop will not exit if your device does not respond. You would have to implement a timeout using a small state machine.

(Would you have rather waited until Monday for the news?)

Well no not really but... I just wonder if I am the only person in the world that got their certification on April 1. But hey I'll take it! The other irony was that I got this while in a meeting with one of the best LV programmers I know of.

Since I just passed the exam It is only fair that I answer my own questions

1. How hard was the CLD? More difficult than I expected compared to the old practice exams. The new practice exams are much better. Ignore the old ones! The only "difficult" part was the time. No time to think about or do anything else at all. Four hours goes very quick!
2. Did you pass on your first attempt? Nope
3. How much experience did you have prior to taking the test? About two years but my first experience with LV was eight years ago. This two years was before taking any NI classes.
4. Did you take the NI courses and if so which ones? Core1 - Core3 first time (Took the exam within 30 days of Core3), Advanced Architectures, Managing Software Engineering in LabVIEW and OOP (old course format) this time.
5. Were you confident after the test that you passed? Not at all the first time. Much more confident this time.
6. What was your score? (I feel kind of weird asking) I did very well on style and documentation but completely blew it on functionality the first time. This time I was able to get most requirements implemented.
7. Did you finish with any time to spare? Not even close
8. Was the project complete? All requirements met? About 75% this time. First time maybe 2% although many requirements existed in SubVIs. I just didn't have time to put the top-level vi together. Bottom up first time, top down this time.
9. Did you fit everything into a 1024x768 diagram? The first time yes. For the passing exam no.
10. When did you take the exam? First time about seven months ago, this time on March 15
11. How did you document algorithms? VISIO or something else? Just pencil and paper state charts or does that have to be in the code? Simple comments on BD
12. How much time did you spend on studying the requirements and planning before starting to code? About 45 minutes. The last 20 minutes of that included creating FP while thinking about requirements and how to implement them. The first time I started coding within ten minutes.

The first time around I spent way too much effort on style. I set my monitor resolution to 1024x768 and made sure everything could be seen without scrolling. I think this got in the way of the all important functionality category by slowing me down. On the passing exam I didn't worry too much about it. The BD was not huge but did require some horizontal scrolling reflecting the way I normally program. I lost one point on style but it was not for this.

So my advice is to not try so hard in the style category to the extent that it slows you down. Just be reasonable. Create the icons and documentation before creating any code so you don't forget. Same for the front panel control typedef control and indicator descriptions and tip-strips.

I got my passing CLD results from NI today. Did they have to send it on April Fools Day?

Since you want a single file for each plugin, you're limited to packaging the plugin in a dll, ppl, or llb. I have no idea what Labview code compiled into a dll looks like to other Labview code. Maybe it would work...? Using PPL to do this is finicky at best. I haven't used LLBs either. Do library VIs retain their namespace and visibility when placed in an LLB? That might end up being the best solution, though I don't think you will be able to have any parent-child relationships inside the llb.

The problem with llbs is that it is a flat file structure meaning you can not have two vi's with the same name. No dynamic dispatching for one. Other than that libraries will retain their namespaces. A problem with packed project libraries is that vis they contain can not be inlined. I ran into that when trying to build the LapDog Message Library into a ppl. I have never used dlls so no comment.

One thing I am considering is a source distribution in a zipfile. My app would have an "Install new plugin" function that just unzips the file into the plugins directory. Another thought is that when the initialization sees a zipfile in the plugins directory it unzips it and removes it. Then I have all the benefits of deploying a single file while still using a run of the mill source distribution.

Creating plugins where no source code dependencies exist between the application and the plug ins is a little trickier, but it can be done. The solution is something called The Dependency Inversion Principle. The DIP states:

• High-level modules should not depend on low-level modules. Both should depend on abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.

Just trying to understand. Is this like the Java Virtual Machine which decouples your code from the OS?

I would use a project file but I don't know if that makes a difference for your score. Your timer uses the tick count function. There is always a risk of a rollover. Get date time in seconds is much better. Just add a to double to it so you can do comparisons. I don't know what I would give for a score but I would definitely give you a passing grade.

Ooops. Don't do this.

I think that heroism is all about motivation. Extreme acts of bravery against all odds don't count as heroism if it servs only to save ones own ass - that is simply the survival instinct. If one knowingly places himself in danger to save others from danger with no promise or expectation of reward that person is a hero. A hero acts for the greater good. Dang socialists!

I built an LVOOP solution for my CLA exam - all I can say is that it does add a large overhead in terms of time and documentation.

Mark

When did you take the exam? Was it after they changed the format? I heard that it used to be some essay questions and a couple hours coding but now it is all coding. From your comments about requirements tracking it sounds like you took the newer one. If so I would be very interested in your opinion of how closely the single CLA sample exam compared with the real exam. Does it more closely resemble the actual exam than the CLD practice exams vs the real ones?

Thanks for the detailed review! I have read many of your posts and you have earned much respect.

It could have definitely been better but with the four hour time crunch and all. It's just not enough time. It took four and a half hours to do and I should have saved a copy away at the four hour mark and posted that. But it would have gotten about one point for functionality.

I used LVOOP for a couple of reasons. One was just for the sake of it because I want to get as much practice. Another is that it seems easier for me. You do end up with a lot more vis to document and make icons for. But documenting them is easier since they don't do much. I don't know if I will write code in a similar way for the CLD. It depends on what they throw at me.

Maybe this second version of the CLD practice exam (sprinkler controller) will be more exciting for people to review. There are no subvis which are not part of a class.

Sprinkler Controller LV 8.6.zip

This took entirely too long. Much more than the four hours but it was very good exercise. Anyone care to comment on it?

I don't want to review gak's carwash practice exam because I am going to do that one next.

Sprinkler Controller.zip

I would also like to congratulate my new friend on reaching his 1K post birthday.

And lets congratulate him for reaching 41 years today.

If my math is not off this works out to one post about every two weeks of his entire life.

Code is in LabVIEW 8.2.1

I modified SubVI With Errors.vi by adding some file IO (open, read, write, close) and removed the case structure. I set the error in constant to true and in LabVIEW 2010 the numbers I got were:

• SubVI 760mS
• Error 1101mS

As expected there is a performance hit since four prims are checking for an error. But it is rare that I consider performance when making a decision like this. Something is wrong and the vi will be called only once with an error before the application is shutdown or the error is responded to and cleared or corrected downstream.

I know that NI recommends the case structure but I find it cleaner without it. When I write a vi I tend to let its functions or sub vis do their own error checking. If I am using code in a vi and do not know how that code will respond to errors then I will put it in an error check case structure. If I know that the code in the subvis I am using wrap all their code in an error checking case structure then I don't worry about it. But the decision is not about performance it is about Saving The Pixels.

That's a lot of LabVIEW versions you have! I only have one

Just to clarify, I don't mean to imply that I think wrapping an entire sub VI block diagram in an error cluster is pointless. In fact, there specifically *is* a point in doing it--to ensure the sub vi code doesn't execute if there's an error. Turns out that's not a goal that contributes to my code quality or clarity when applied universally to my projects. *shrug*

Or to ensure that the sub vi code DOES execute if there is an error In fact I just wrote a vi today that does nothing in the no error case but in the error case it generates a user event.

I didn't mean to imply that I think it is always pointless. I said "mostly" although a better word would have been "usually". There are many situations where it is definitely a good thing and even necessary. I know we are on the same page but what I meant to say is that error cases are usually a waste of a some perfectly good pixels.

Take for example a vi that opens a file, reads it and appends a string, writes the results then closes the file. It would be pointless in this vi to wrap those functions in an error case. If you call the vi with an error in then those primitives already skip what they do in an internal error check. But I suppose that there is a difference in that the open, read, write and close each have to check for an error where they could have been skipped. But how expensive can that be compared to the normal condition in which there is file IO! In that vi I can see no reason whatsoever to use (or not use) an error case. I just don't see the difference.

This is the way I have been programming for as long as I have been programming. When it comes to an error case I just use one if I need to or if it seems to make sense. But I almost always have error terminals on any vi that I write. When they are not used they are just wired together internally.

For my CLD exam I will put error case structures in any sub vi.

Man you sure can start some threads. First it was the QSM and now this. In both of these you make some very good arguments against what everyone seems to just accept. What next?

I have an important question. I will be doing my CLD exam soon. Do the evaluators check that subvis are wrapped in an error case structure? I know that vi analyzer does. Maybe I should explain in the comments that this is (mostly) pointless and refer the evaluators to this thread

Can anyone from NI that conducts exam reviews comment?

You can interface labview with labwindows cvi or .net. You might also want to look at teststand.

I want to ask a question that is not possible to answer but here goes. How hard was the CLD? I know it obviously depends on experience, knowledge and problem solving skills. Was it really really hard, really hard or just hard?

But in seriousness if any of you would mind answering these specific questions that would be great:

1. Did you pass on your first attempt?
2. How much experience did you have prior to taking the test?
3. Did you take the NI courses and if so which ones?
4. Were you confident after the test that you passed?
5. What was your score? (I feel kind of weird asking)
6. Did you finish with any time to spare?
7. Was the project complete? All requirements met?
8. Did you fit everything into a 1024x768 diagram?
9. When did you take the exam?
10. How did you document algorithms? VISIO or something else? Just pencil and paper state charts or does that have to be in the code?
11. How much time did you spend on studying the requirements and planning before starting to code?

For #8 I am thinking that I will just take a hit on style if doing so helps me get more functionality out..

For #9 I heard somewhere that the test recently became more difficult around the time that the new example exams were released.

I have always wondered about that. I mean if I am just unbundling something what can go wrong and why do I need to skip that on error in? It never really made a lot of sense to me but I blindly followed the advice to wrap all the content of my subvis in error cases. Now I will only be doing that if I actually will be putting code in the error case or if I really think I need to skip the code in the no error case on error in.

Does anyone know how to modify the templates used to create accessor vis?

Uhm.. This has nothing to do with the thread but it is killing me. What the heck is a GutStep?

No that is wrong. Just wrong. Now this one will make anyone feel better about anything.

http://www.youtube.com/watch?v=pnoaj8b2bGM

I have not read your book but I can totally understand your frustration. The sole review for a book on image acquisition says it is not a good book for learning labview?

I read a review on the labview style book complaining that it focused too much on.... style and not enough on the basics. I take it as a positive about your book that you apparently didn't waste chapters explaining the things a labview programer should already know before buying a book on a specialized application area.

I would write something there but I can't seem to find out how to post a review from my phone and won't have access to my laptop until tomorrow.

Thanks. It's on order. I hope there is a new edition in the works just in case the author is reading.

Do any of you recommend this book? The amazon site has some pretty negative reviews but all dealing with poor print quality. One of the more recent reviews said that this has been fixed. My biggest concern is that the book seems old. I think it predates LVOOP.