I'm not a CLD and never took the exam, so take what I'm saying with a grain of salt.
Let's start with ameliorations I would suggest:
1- You've put a "Wait Until Next Millisecond" and you use a 75ms timeout on your Get Queue primitive. If you were to remove it altogether, you'd still have the 75ms timeout to slow down your loop, except when you have something waiting in Queue.
2- That gets me to your use of the Queue repetitively for each of your actions. You parse the same string to the queue unless the time is elapsed, in which case you reset and move on. That works OK in this case, but in real life, you'll want to start a process, say "Main Wash" and you can't do that repetitively until it's finished. In fact, you call "Main Wash" a hundred times before it moves to the next action in the list. There are probably ways to salvage your design to make it call each car wash action only once while keeping track of time and position switches.
3- Probably minor, but your Queue wire is bent around a Case Structure for each car wash actions. It would probably be better style to try straightening it.
4- Your Default case executes the same code if your queue reads an empty string (timeout), "Wait" (which I haven't found in your program) and any other command that is not an handled state. You could add an "unhandled state" diagram that would correspond to your Default frame. If the queue is empty, you could use a "Idle" state (or Wait) and put an Event diagram to really wait for the user to take action of one of the switches to change state. With timeout = -1, you wouldn't have to worry about the processor running to fast when Idle and you could wait for an event to happen.
As a collateral to using an Event diagram, you would have a more expandable program. For example, take your call for activating a car wash selection:
With two choices, it doesn't clog your diagram, but what if you want to add a third one on the fly... or a fourth. You never know what the car wash owner will ask next!
5- I would have added an empty SubVI for each action: Wash, Soap, etc. just to show the routine is being executed in the right frame. To convert your program from example to real-world, only the content of these VIs would have to be filled in.
Positive points:
1- Indeed, the code is simple. You make good use of subVIs for repetitive tasks. That definitely shows you've thought about it before starting to code.
2- You've documentation all subVIs (descriptions, tip strips, frames, wires).
3- Code is clean and a lot of space to breathe. Apart from some minor wire bending, the code is easy to read.
Finally, if you had some loose time left, I would document with a little more meat and make sure the tip strips are differentiated. All your wash state indicators have the same tip strip... (Do what I say, not what I do... most of the time I don't do that myself, except during exams!!! )
Good luck getting the CLD! Keep us posted.