Summer Labview Challenge 1

[Bpk9p4]

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
1) Green Light (True / False)
2) Yellow Light (True / False)
3) Red Light (True / False)
Outputs

1) Go (True / False)
2) 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
1) Green Light (True / False)
2) Yellow Light (True / False)
3) Red Light (True / False)

Outputs
1) Go (True / False)
2) Stop (True / False)
3) 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.

[GuyM142]

Are case structures allowed?

Edit:
My solution in the link: http://oi60.tinypic.com/x5rvpe.jpg

[Bpk9p4]

i did not intend case structures to be used. Your solution looks great. it is really close to how i did it

[Alan Anderson]

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.

[Ari423]

Here's my submission:


Also I made a fancy front panel for fun:


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.

[Bpk9p4]

These all looks like great answer. Always fun to see the different way people solve the same problem.

If you guys have any suggestion for future challenge please let me know.

[Jonathan L.]

Another fault condition would be if none of the lights are on.

A timer might be a good challenge.

[Ari423]

Originally Posted by Jonathan L.

Another fault condition would be if none of the lights are on.

Mine actually does that too. It shows no fault iff exactly one light is lit.

[aeastet]

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.

[aeastet]

If you do not know how a snippet works:

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.

[Ari423]

Originally Posted by aeastet

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.

What is the purpose of the fault detection if you use the event structure loop to ensure faults are impossible?

[aeastet]

Originally Posted by Ari423

What is the purpose of the fault detection if you use the event structure loop to ensure faults are impossible?

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.

[aeastet]

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.

[Ari423]

Originally Posted by aeastet

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.

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.

[aeastet]

I also sent you a suggestion for a challenge. Check your messages.