This week my labview class learned all about Boolean logic so this weeks challenge is all about Boolean logic. For this challenge you can only use Boolean logic. I highly recommend you only use AND, OR, and NOT. The challenge is based around a stoplight game you have a green, yellow and red lights. Your robot can be moving when the light is green it cannot be moving when the light is red. There are two parts to this challenge. Fell free to ask question and post your answer on here. I will post my answer to the problem on Tuesday.
Part 1
Your program will have 3 inputs and 2 outputs
Inputs
Green Light (True / False)
Yellow Light (True / False)
Red Light (True / False)
Outputs
Go (True / False)
Stop (True / False)
The challenge is to have Stop = True when the light is Yellow or Red and Go = True when the light is green.
Part 2
Your program will have 3 inputs and 3 outputs
Inputs
Green Light (True / False)
Yellow Light (True / False)
Red Light (True / False)
Outputs
Go (True / False)
Stop (True / False)
Fault (True / False)
The challenge is the same as above however if more then one light is on Fault = True, Stop = True, and Go = False. The reason we are checking for faults is we always want to make sure you sensor is working correctly.
Since there are only three Boolean inputs, I took a different direction. The Input control is a cluster of three buttons (Green, Yellow, and Red), and the Output indicator is a cluster of three LEDs (Go, Stop, and Fault). If you run the attached snippet, you can see them on the front panel.
I think the converting to integers makes the code look nicer and easier to read, even if it is illegal. I decided to fail safe, and I think most would agree that it is better for a car to stop rather than accelerate if it gets a bad reading. As always, open to questions, comments, and concerns.
Here is my solution. This is also a snippet. We made the stop and go one light. We added a blink feature to the fault light. We did not use the default blink because it really isn’t very nice. Then we added the upper loop with the event structure to set the lights so no more than one can be pushed at one time.
If you open LabVIEW and drag the picture into the block diagram it will add all of the code from the picture posted as long as it is a snippet. It is very cool.
If I know I can have a fault condition I will try to do what I can to make sure that I can not have it. Sometimes this is impossible but in this case I added code to prevent someone from hitting two buttons at once. I would do this in my software if I knew the condition existed. This way there is now no way for the operator to accidently hit two buttons when they get excited in a game.
As we went through your challenge we solved each step. Then I added one more challenge to make sure that you could not get yourself into the condition to have a fault. If you delete the event structure you will find that the code does exactly what you challenged. I am just trying to get my students to think about the whole problem and not just solve the answer. If there is a condition that can put you in a fault can you prevent it? If so do it.
We should always be thinking about a way to make our software repeatable, easy to expand, efficient and as error proof as possible. We need to think of how the operator is going to use the software and then watch them and see how they really use it. We improve the robot all year long so I challenge the programming team to make the code better all year long.
Makes sense. We do a similar thing by holding the first press of the buttons rather than using the buttons themselves (it’s complicated to explain). I didn’t recognize it done using the event structure.
