NI Traffic Light CLD Soln vs mine

[RevaD]

Thanks for looking altenbach and thanks for the tips; some good techniques especially the feedback node to eliminate the loop; I'll have to try that one.

.

richjoh here is the LV8.2 version, I also corrected a slight error in the light sequence.

Many thanks,

Dave.

[richjoh]

I see your rotating an array to sequence the lights, the case for the East left turn light is included in your type def and East left turn works. The other direction cases are not included and does not work. Hmmm, wondering if the addition cases would disrupt your sequence scheme. Of course we are just talking about functionality here. I'm not so sure NI would agree with your "Style" and "Documention".

I agree with Altenbach no 1 and 2 points. His 3rd and 4th not so sure, I  never done what he's suggesting... its easier said then done.

Message Edited by richjoh on 01-16-2009 02:31 PM

[altenbach]

---

RevaD wrote:

Thanks for looking altenbach and thanks for the tips; some good techniques especially the feedback node to eliminate the loop; I'll have to try that one.

---

I agree, the buttons don't work right. I have spent a few minutes to apply my suggestions and do some general cleanup.

I probably would do things quite differently, but let's stick with your code and just refactor it without (hopefully) changing any functionality or programming logic! 🙂

In the subVI, the boolean shift register does not need to be initialized, because with is guaranteed to be TRUE from the previous subVI call (else the previous call would not have terminated!). At the first call, we call the first element, so it will be set to TRUE anyway.

In the main VI, you take the old cluster and overwrite everything except the four switch boolean (top of picture). Wouldn't it be simpler to take the new cluster and replace the old switch states instead (bottom picture)?

Here's a quick draft of what I meant for the subVI. Keep the states as a diagram constant and rotate trough a numeric index instead.

So, again I repeat, I retained your code and just cleaned it up a bit. Note also that it is recommended to place terminals outside the loop (e.g. "current sequnece out" ) for more optimized code.

Message Edited by altenbach on 01-16-2009 02:28 PM

[RevaD]

Thanks again, I did originally update the culster the way you advised (update the whole cluster then restore the switch values) but I thought the long way was actually more logical to what was actually happening so I changed to that.

Thanks everybody for the help. I'm goging to try to implement the full sequence with all switches soon to make sure that works.When I've got everything as correct as possible documentation wise I'll try to post it again.

[drjdpowell]

I haven't done the CLD myself, but this conversation prompted me to look at the Traffic Light example exam, along with the NI-supplied sample solution.  Although I'm sure it follows standard "style", IMHO it is a pretty poor attempt at the described problem, at least if this were to have any connection to a real-world problem of programing a traffic intersection.  

1) Real-world intersections come in many different configurations, but the solution presented is inherently specific to only one very-specific configuration with no thought applied to producing software that can be customized.  Every different intersection type would require a different version of the code.  A fully general solution is too big for a four-hour test, but one could at least set the groundwork by having some "intersection configuration" constants feeding into a more generalized intersection state machine.  It would be easy to write code that could be configured with an arbitrary number of lights and states by using arrays, for example, allowing easy generalization to a five-way intersection.

2) The solution ties together the implementation of the intersection state machine and the implementation of the specific type of light. If traffic engineers were to start using four-bulb lights (Red, Y, G, and Left Turn Arrow) then the entire intersection code would have to be modified.  The code should be more "modular"; there is no reason why a programmer implementing a new type of light needs to delve into the details of the intersection, nor does the intersection programmer need to know which specific light bulb signals "Left Turn".  

The clean coding and extensive documentation is nice, but useless if the code becomes obsolete the instant it confronts the first real-world complication.  Admittedly, this is just a test question constructed from a predetermined answer, and the test-taker should be able to guess what the test makers really want in place of an actual scalable design.  

 -- James