CLD Prep-Car Wash Review

[Lukin]

I was wondering if anyone could spare a few minutes and look over my solution to the Car Wash sample exam.  I did this timed and stopped working when the clock hit 4 hours.  After stopping I noticed that there is a small bug in that when the "Low Pressure Wax" LED is supposed to light up the "Under Body Wash" does instead.  Other than that I feel pretty good about it.  I really appreciate any feedback given.  The problem specification is included in the zip file.

Thanks,

[JÞB]

overall you chose a pattern that will work. you will get a few dings though.

1. Wire bends- you could have avoided some the'll take the style point off for that
2. Wired terminals not on root BD (Search for "Clear as mud") and bring a good cup of coffee
3. I'm a big fan of "Code it once"  What could you have done differently the set the "Wash entry" properties? think about it and how you could have used the State value to hide all those BD constants that Main doesn't need to act on.

[Lukin]

Thanks for the quick reply.  A couple quick questions if you don't mind.  

"2. Wired terminals not on root BD (Search for "Clear as mud") and bring a good cup of coffee"

I read through the clear as mud post.  I had never even considered that thanks for the great info.  I will have to think about it a bit more before I can say I really understand.  But as an example I should change the top code into the bottom code.  Correct?  

"3. I'm a big fan of "Code it once"  What could you have done differently the set the "Wash entry" properties? think about it and how you could have used the State value to hide all those BD constants that Main doesn't need to act on."

Now that I look at that I am not sure why I did it that way.  Clearly the best way to do that is just to set the color and text based on the true/false state sent to the control and set it to true or false as needed. 

Thanks for your reply.  It is much appreciated.

[JÞB]

---

@Lukin wrote:

Thanks for the quick reply.  A couple quick questions if you don't mind.  

"2. Wired terminals not on root BD (Search for "Clear as mud") and bring a good cup of coffee"

I read through the clear as mud post.  I had never even considered that thanks for the great info.  I will have to think about it a bit more before I can say I really understand.  But as an example I should change the top code into the bottom code.  Correct?  

---

[JÞB]

I may need to edit that response later---- Some info was lost or there is a bit of forum maintainance going on.

[JÞB]

---

@JÞB wrote:

---

@Lukin wrote:

Thanks for the quick reply.  A couple quick questions if you don't mind.  

"2. Wired terminals not on root BD (Search for "Clear as mud") and bring a good cup of coffee"

I read through the clear as mud post.  I had never even considered that thanks for the great info.  I will have to think about it a bit more before I can say I really understand.  But as an example I should change the top code into the bottom code.  Correct?  

---

---

Yes, and NO!

Yes, the vi behaves much better with the "Wired Terminals" (those connected to connector pane terminals) outside any structure.  I warned you to bring a good cup of coffee when you read that thead.....It eventually does make sense if you really consider breakpoints outside the structures.

NO! what are you doing "Polling" an enqueue event?  There are times when this is useful but what you have here is a "Command" to start an autonomous process governed by an overseer.  Essentially  "Attention," "Forward March," "Halt." 

you are polling when you should be enquing to self "Left, Left, Left-Right-Left"  Your Drill instructor doesn't care HOW you "March" he expects you to do it!  But, you need to listen for that "Halt" command.  (The Drill instructor knows where the cliff is, the actor is a lemming)

Enqueue to self!  Enqueue opposite end from the overseerer in this design pattern.

Usually the differences between a "Master / Slave" and a "Producer - Consumer" design pattern is divided into Notifier vs Queue.  the Slave acts on the last command but has no autonomy, the Consumer operates on all commands.  With an "Actor" you need a priority queue to act on the master's commands and possibly ingore or change the slaves autonomous behavior. 

[Lukin]

Wow that went in a direction I was not expecting.  So this is a method that I use form time to time and now you have me questioning it.  I relies that I am basically using the dequeue as a wait timer when there is nothing on the queue.  Normally when I do this I am expecting there to be times when I would have more than one element on the queue and I want to pull them off in order and have something else happen when the queue is empty.  I suppose in this case I am not really going to expect things to stack up in the queue like that.  I chose to do it this was as its what I know and it did not make sense to try something new on an exam.  

In this case I wanted the "Start Wash" case to be able to run if there was nothing on the queue so that I could run through the wash sequence.  But at the same time be able interrupt that if the user selected stop.  As I look at it I could have done this with a notifier as well but why?  I would have had to still use a timeout on the notifier and done the same thing by basically using it as a wait.  Is there more over head to a queue than a notifier perhaps?  Or am I just way off base for some reason I can't seem to see.  

Sorry if I am going down a rat hole here but I am just trying to understand why what I am doing is bad practice and thanks again for the help.

[JÞB · Accepted solution]

Its not necessarilly bad practice.  Probably more of a personal style.  I would have done something more like this.

[EDIT} Silly snipett tool- heres a CC

Why? it avoids that 50mSec wait between states and still allows the user input to get serviced in a priority manner as soon as the event fires.  Essentially the original code did much the same but was polling a queue to see if an event fired then merging two different feedback schemes (The Queue and the SR).  When you have a lot of different communications going on it can really get confusing just what the source of the "State command" was (SR or Queue).  keeping all commands comming through the queue allows you to easilly add a subvi "Enqueue to My Queue.vi"  where you can add history and logging if the data passing scheme gets very complex. 

For the CLD exam you won't have to worry much about the differences (Really, it is a fairly simple project not 500 vis) but, you asked so I felt I owed you the answer.

In this case a notifier isn't quite the ticket either since, the start and stop commands won't "Latch" they could get overwritten by the Actor loop.  So there is a good reason for enqueue opposite end to exist.

[Lukin]

Ok that makes a lot of sense.  I have never run into a situation where I did not know where commands are coming from but I can see how it might happen and could be a real pain to debug.  Thank you very much for the detailed response.