Showing results for 
Search instead for 
Did you mean: 

Sample Exam Solutions for Review


The reason that the enter key events need to happen twice is becuase the user input value arrives at the event structure at the beginning of the loop iteration but it doesn't read the current value whenever the enter button event fires (you'll see that if you turn on highlight execution, or use a breakpoint/probe inside the event structure). You need to either move the user input into the enter button event (preferred becuaes it's a direct wire) or use a local variable to read the current value (bad style though - it breaks dataflow). You can also use a property node of course, but they are slower than a local variable if all you need is the value.


As you'll see in other people's solutions, it's easier to have a single state and event strucutre for all possible uses of the enter button, but assign a kind of command by using a seperate enum and case structure. If you think about it, the enter key is a sub-state machine in itself becuase it changes it's data and behaviour depending on the value of other preceding states or input data.

0 Kudos
Message 41 of 554

I may try the CLD test in a couple of weeks. Here's the ATM exam written in LV12 with AF package version

This took me about 4.5 hours (though I had to pause overnight at 2.5 hours). I didn't do any planning at all: code-and-go all the way.


The UI is the only actor. I really wanted to make the file I/O an actor of its own, as well as a countdown timer (so their FPs could be shown during DEBUG==True), but I'm not THAT fast. Overall, I'm happy with it, for the time spent. Comments are welcome. Requirements pdf included in zip file and in project.



(Cross-posted on lava:http://lavag.org/topic/16715-atm-sample-cld-exam-written-with-actor-framework/)


Message 42 of 554

That is fast coding!  Thank you for that nice example.

"Should be" isn't "Is" -Jay
Message 43 of 554

Thanks, Jeff!


Here's the Boiler. It took me about six hours, but I spent time writing it in a way that will let me ask practical questions about the theoretical considerations of the Actor Framework.


0 Kudos
Message 44 of 554

Hi All,


This is my first complete practise exam (Carwash). Everything done under the 4 hour limit. I aim to complete 2 more over the next few days before my exam on Thursday (gulp!) If anyone could take a look over it and identify things I could improve on, your help would be enormously appreciated. I know I failed on a couple of points like tip strips and labels for some constants. I tried to comment extensively but I may not have described the algorithms sufficiently.

The big thing I'm unhappy with is that the code is vulnerable to people changing the order of stations on the slider control. As the slider control is not an enum, the numerical check I did against it was very dirty. I'm also unhappy with my code that parses the user options and generates the wash sequence as it's not very elegant. If someone can point me in the direction of a more succinct way of doing it I would appreciate that too!

Looking forward to hearing from you guys.


Kind regards,


0 Kudos
Message 45 of 554

Hello again all,

Here is today's attempt, this time on the ATM exam, completed in 4 hours. I found this one to be a LOT harder than the car wash. I'm looking for any and all criticism. Things I was unhappy with:

  1. The Parser generates a whole array of all User's information, rather than just the one I want. The reason I did this is I couldn't figure out how to overwrite a specific row in a .CSV file. So I just overwrote the whole file with updated array. Obviously this is going to use a whole lot of memory if you're dealing with an actual bank's list of clients (many thousands).
  2. I didn't have much time to do the commenting properly. I think I might have even missed a sub VI?
  3. The exam makes mention of making future menu changes easy to implement. I feel like my architecture does so, but it's not that great (for example, not a simple matter of changing some sort of .ini file). Do you guys see my choices as being scaleable or did I blunder really badly?



  1. At a CLD preparation session, we were told we could use templates from Labview (i.e. QMH templates etc.). I just wanted to see if anyone had been told not to use LV's built in templates? I think I could have gotten a lot more done if I'd let myself use them rather than building the whole QMH from scratch (as you can see, it's pretty ghetto).
  2. Would I get marked down for using the dequeue timeout to check if the user hasn't done anything, rather than writing an FGV timer?
  3. I've noticed that when file IO is required the file format is usually.CSV. Can I assume that this will always be the case? I actually spent about 15 minutes writing a string parser for this before I realised how to use the read spreadsheet stuff (this is also why the File IO thing is an AE rather than a simple read).

Would love to hear from you guys about this one and the previous one I posted if you've got time.



0 Kudos
Message 46 of 554

Hi Everyone, 


I have just started prepping for my CLD exam. This is my first attempt at an example question and would appreciate any feedback.


It took me quite a bit longer than the required 4 hours, but I know with practice I will get a lot quicker. 


Thanks in advance for any feedback.




0 Kudos
Message 47 of 554

Hey I know I'm in the same boat as you. I don't seem to be getting much luck with people responding so I'll respond to yours.


  • I really like what you did with the ATM messages Action Engine. I didn't think of doing that with mine and it's very nice.
  • Why didn't you fold the accounts text array into your program data wire, especially given it's shift registered across the consumer loop?
  • With the update display case (and this is my personal criticism as opposed to an actual grounded in experience one). I don't like Producer Consumers that are allowed to enqueue to themselves, especially for sequencing critical operations (I know UI update isn't critical). As such, I went and figured out how you would update the indicators in their QMH template, you grab your typedeffed cluster of UI indicators, create another dynamic event (to do it requires bastardising the "Creat STOP Event.VI" a little bit) with the the type-deffed indicator cluster as the data type. Then just trigger it whenever you need to update.
  • Your BDs are HUGE, another tip I saw was to change your screen resolution to the 1024x768 recommended limit to make yourself more aware of it.
  • Cool enable/disable controls VI!
  • You have some inconsistent error wiring of things like property nodes (sometimes wired, sometimes not).
  • Architecturally, yours is very similar to my attempt, which I found reassuring. Out of curiosity, what was it in your mind that pushed you towards QMH rather than State Machine?

Hope some of this is helpful, would love to get your thoughts on mine if you have time?



Message 48 of 554

Wow thanks for the quick response, really helpful.


  • Putting the array into the data cluster - didn't think of that but great idea.
  • Inconsistant wiring - I'll keep an eye on that. Making changes at 4am isn't a good idea I reckon.
  • HUGB BD - Changed resolution. 
  • Enable/control VI's - Cool idea I copied from LabVIEW Core 3
  • Architecture - I did LabVIEW Core 3 a few weeks ago so trying to use what they taught us there. They were really pushing producer/consumer

Now to your program:


I have never had to review someone elses code before so please bare with me. I'll try to be as clear and precise as possible.

After looking at your code, I think mine was really overkill and no wonder it too me so long. Going to have to refine my process to get in under 4 hours.


  • Check your wiring. Try to use as few corners as possible. In your event handling loop, some of the Message.ctl constants are over wires or the enqueue function. In your DQ Message.vi, the queue out of the dequeue element goes behind your error case structure. It's clearer to take it over the top. A good tool to use if you have it is VI Analyser. I only have the student version so don't have it but have used it in th past. 
  • Documentation - You have no Destriptions or Tip Strips for your main FP controls and indicators. Worth 10 points out of 40 so worth doing.
  • Another way to do your timeout could have been to use the built in timeout function of the event handler. Just my opinion as both work just as well.
  • When you convert the account number in ParseStringsForAccountDetails.vi, it might be a good idea to check for characters or invalid acount numbers.
  • All your ATM Messages seem to be hard coded so not very easy to expand.
  • I like what you did with your file reading/writing handler. I also thought of how to just update one element, balance, but ended up rewriting the whole file. An ini or xml file might have been a better choice to use.

Well I hope that helped.

Happy coding,

Message 49 of 554

Hi Alex,


The application appears not to be saving the balance changes.  When the app runs a second time it doesn't show changes made in previous run, like a deposit for example.  The Main Icon is not representative of the functionality.  There are a couple of uses of the default values on the structure edges and there seemed to be several wires under structures.


Overall I would say the application has most of the functionality, especially the core functionality, which for the ATM would be the transactions.  If this was completed in four hours then     it would be a passing effort.  Keep in mind this is an informal review covering for the most part just the functionality as I remember it. 🙂



Mark Ramsdale
Program Manager & CLA
Global Demo and Equipment at National Instruments
0 Kudos
Message 50 of 554