SteveChandler

Did you wire the shift register through in the other case, the zero case? That case should be empty other than wiring the shift register through. As for the UI freezing this can be expected. The UI will freeze until everything in the event structure is done. You can try right clicking on the event, select edit events handled by this case and unselect Lock front panel at the bottom. That is not the right way to do this and you should read the help to understand what the implications are. It is recommended that you put all of the processing in another loop outside of your event loop. It means rewriting your application to use a producer/consumer architecture. There are many good articles about this. Have you used the LabVIEW project? With one vi like you have it doesn't make a lot of sense to use it. But if you were to rewrite this to use a producer/consumer design with subvis and typedefs it really helps.

Now I can see that you are explicitly disabling the termination character so I guess that answers my question and you know your device does not send one. You changed the wait to only 5mS. Highlight execution would cause a much longer delay. Try changing it to 100 or even 1,000 as a test to isolate the problem. Maybe you already tried that but it is not clear. I can see that the combo box has empty values after the first one. Is that what you see when putting a probe on the input to the Strings[] property node? I also notice that you are using the same pattern of write, wait, read in many places. You should make that into a subvi. I also changed it so that the array of strings is built in a shift register. But after looking more closely I am kind of confused. I thought that you were creating the combo box entries from the results of the read. It looks like you want to create entries if the read returns something other than zero and the entry is the for loop iteration in hex. I did not notice that the N terminal had a 50 wired to it. I can not figure out how you only have three entries in your combo box instead of 50. Can you try putting an array size function on the input to the property node and see what that returns? [EDIT] Ok now it makes sense. The code you posted is not the same as the image you posted above. In the code image above you have a three element string array constant auto indexing the loop. No wonder I didn't notice the 50 wired to the N terminal. It wasn't there before. Just a side note and I hope it doesn't sound preachy. Personally I always keep the block diagram as neat as possible and don't worry much about the FP. I live in the BD. When my mind is busy thinking about how to solve a problem I sometimes use that time to clean up wires and arrange nodes. I only do this with parts of the code that have something to do with the problem to keep my thoughts focused.

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.

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 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?

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.

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!

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

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.

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

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: Did you pass on your first attempt? How much experience did you have prior to taking the test? Did you take the NI courses and if so which ones? Were you confident after the test that you passed? What was your score? (I feel kind of weird asking) Did you finish with any time to spare? Was the project complete? All requirements met? Did you fit everything into a 1024x768 diagram? When did you take the exam? How did you document algorithms? VISIO or something else? Just pencil and paper state charts or does that have to be in the code? 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.