Gee, it just occurred to me... I wonder how many actually go through the pains of completely reading through my long-winded posts... hmmm... I just wondered... Am I really blowing just so much hot wind?
As specified (probably by a very poor trainer, or book, or a very poor interpretation on the part of the student)... the solution to the problem is somewhat untenable, unless you work with "implied" information. That is NOT to be expected, or accepted, in the real-world.
Poor "specs" can lead to poor implications... that is, results based on implied questions or responses based on implied logical situations. On the whole... that is a HORRID situation to work under! It is DOOMED to failure... at least, in the eyes of some (the Contractor?).
To the issue, as described...
If 1-ON & 2-ON... OUT-ON. This is an absolute constraint.
Once OUT is ON... it will remain ON as long as either 1 or 2 are ON... until the OFF-Condition occurs.
In order to turn OUT OFF... 3 MUST go ON... WHILE OUT IS ON... and while one, or the other, of 1 or 2, but not both, is OFF.
However, there is another absolute constraint... if 1-ON & 2-ON & 3-ON then, OUT-ON.
So... in order to turn OUT OFF... it MUST be the case that either 1 or 2, but not both, MUST be OFF.
Starting with all Inputs OFF, and assuming that Inputs go ON one-at-a-time... a normal ON-OFF sequence would have to follow one of the following possible sequences (X-ON, X-OFF, X-ON doesn't count)...
Case-1:
1-ON, then 2-ON... => OUT-ON (1 & 2 = Latch OUT-ON)
-OR-
Case-2:
2-ON, then 1-ON... => OUT-ON (1 & 2 = Latch OUT-ON)
-OR-
Case-3:
3-ON, then 1-ON, then 2-ON... => OUT-ON (1 & 2 & 3 = OUT-ON and 1 & 2 = Latch OUT-ON)
-OR-
Case-4:
3-ON, then 2-ON, then 1-ON... => OUT-ON (1 & 2 & 3 = OUT-ON and 1 & 2 = Latch OUT-ON)
-OR-
Case-5:
1-ON, then 3-ON, then 2-ON... => OUT-ON (1 & 2 & 3 = OUT-ON and 1 & 2 = Latch OUT-ON)
-OR-
Case-6:
2-ON, then 3-ON, then 1-ON... => OUT-ON (1 & 2 & 3 = OUT-ON and 1 & 2 = Latch OUT-ON)
Now... how can OUT be turned OFF???
The "spec" says... if 3 goes ON while OUT is ON, then OUT
will go OFF.
However, there are absolute constraints that will keep OUT ON!
In order for OUT to go OFF... it MUST be the case that none of those constraints be present, and further, that 3 goes ON while OUT is ON.
That is... all "causes" to go ON, or be ON, must be removed before the "cause" to go OFF occurs.
So... in light of this... a better "spec" would have said...
1. If 1 & 2 is ON, then OUT will go ON, and remain ON as long as either 1 or 2 is ON.
2. If 1 & 2 & 3 is ON, then OUT will be ON.
3. If OUT is ON, and either 1, or 2, but NOT both, is ON... and then 3 goes ON... OUT goes OFF.
If this is indeed the "spec"...
Then... there are actually two ways to turn OUT OFF...
One way is for 3 to go ON WHILE either 1 or 2 is OFF, but NOT both, AND OUT is ON.
The other is for both 1 & 2 to be OFF.
K-MAP... You have to follow the Inputs. HOWEVER... be aware, many of the various paths are NOT valid! Consider the Map in terms of the constraints.
3 OUT
1 2 0 0 0 1 1 1 1 0
+-------+-------+-------+-------+
0 0 | OFF | Turn | Turn | OFF |
|(Wait) | OFF | OFF |(Wait) |
+-------+-------+-------+-------+
0 1 | OFF | ON | Turn | OFF |
|(Wait) |(Wait) | OFF |(Wait) |
+-------+-------+-------+-------+
1 1 | Latch | ON | ON | Turn |
| ON |(Wait) |(Wait) | ON |
+-------+-------+-------+-------+
1 0 | OFF | ON | Turn | OFF |
|(Wait) |(Wait) | OFF |(Wait) |
+-------+-------+-------+-------+
Typical path is...
0000 to 0100, or 1000... wait...
Then 0100 to 1100, or 1000 to 1100... latch OUT... 1101.
Then, if 1101 to 0101, or if 1101 to 1001, then... Hold OUT, 0101 or 1001.
Then, if 0111 or 1011, then, turn OFF OUT, and maintain 0110 or 1010, and wait.
Notice that 1111 to 0111, and 1111 to 1011, is NOT valid
I'll have to carry on a bit later...
Except I will say this...
The BANE of ALL Engineering effort is a poorly defined problem!
The hardest part of being a player here at PLCs.net (I got it right that time, Phil!) is the extreme effort that we players have to put in to Reverse-Engineer the question.
One of the very first things I learned in Engineering is... When facing a problem... What is the REAL question?
Defining problems completely, and accurately, is damned near an art in itself!
I said "damned near"... I'll take that back...
90% of REAL Engineering IS INDEED
properly defining the question!!!
Solutions are question-based... The hard part is to properly define the question!
If you don't really, and I mean REALLY, know what you are seeking... how in the hell can you possibly expect to find the right answer???