Using a PLC to program a Tic-Tac-Toe Game

I'm a college student who is just now beginning to be aquainted with the inner workings of a PLC. Currently my partner and I are working to
make a Tic-Tac-Toe Game using a PLC with 16 inputs and outputs. Basically, we would have one gameboard surface with 9 holes. The two players would try to roll their balls into the right hole and the first one with 3 straight wins. There would be sensors at each hole to indicate when a ball has gone in there or not.
We have some ideas on how to get started, but we still could appreciate any advice on how to contruct the ladder program and what the cheapest, most effective sensors to use are.
Thanks for listening.
Jeremy
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Only need 3 outputs and 6 inputs to scan a 3 x 3 x 2 crosspoint switch matrix of columns and rows. Ball in a hole makes a switch for X or O in that hole, ( 2 output contacts per hole ). I'm thinking different weight balls for X and O and microswitches that need the different pressure to activate. OR maybe one ball is conductive and other is not, plus a little logic to get X, O or NO hole output.
The 3 columns are repeatedly scanned one at a time in sequence for say .1 second each. While a column output is turned ON, the 3 HOLE - 6 inputs are read in to determine which switches in that column are ON. Each switch has a bit in a DWORD register ( 18 of 32 bits of DWORD used ), call this the scan results register. The DWORD id checked against a lookup table at start-end of scan to determine if someone has won.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Jeremy,
1 - Two varieties of balls, one black and the other coated with aluminum foil. Making them reasonably heavy will simplify your job. Don't fall into the trap of attempting to miniaturize everything.
2 - At the bottom of the hole is a small limit switch. Get one from an old mouse. This will detect the presence of a ball. (any color.)
3 - At the sides of the hole put a several, simple, wire contact points. Wire them in parallel to make one pole. Put the other side of the contact on the limit switch tab. The sensing volatage, typically 24 VDC, comes from the PLC.
4 - Each of these sensors become a PLC input. Scanning or multiplexing is far too complicated for such a simple problem. These make a total of 3*3*2 = 18 inputs. A typical PLC DI card has 16 or 32 channels. There will be enough left to provide for RESET, lamp test, etc.
Label the switches: A 1 B for row A, col 1, ball, etc.
Label the contacts: A 1 S for row A, col 1, silver.
5 - The first block of logic would deal with identifying the presence and color of a ball:
A1X = A1B and not A1S (black ball in A1) A1O = A1B and A1S (silver ball in A1)
In ladder logic these would look something like this:
---[ ]----------[/]---------( ) A1B A1S A1X
---[ ]----------[ ]---------( ) A1B A1S A1O
5 - The next block of logic recognizes a winner:
WINX = (A1X . A2X . A3X ) + (B1X . B2X . C3X ) + (C1X . C2X . C3X ) + (A1X . B1X . C1X ) + (A2X . B2X . C2X ) + (A3X . B3X . C3X ) + (A1X . B2X . C3X ) + (A3X . B2X . C1X )
WINY = substitute Y for X.
The ladder looks like this:
---[ ]----------[ ]----------{ }---------| A1X A2X A3X | | ---[ ]----------[ ]----------{ }---------| B1X B2X B3X | | ---[ ]----------[ ]----------{ }---------| C1X C2X C3X | | ---[ ]----------[ ]----------{ }---------| A1X B1X C1X |-----------( ) | WINX ---[ ]----------[ ]----------{ }---------| A2X B2X C2X | | ---[ ]----------[ ]----------{ }--------| A1X A2X A3X | | ---[ ]----------[ ]----------{ }--------| A1X B2X C3X |
6 - You will need some form of lockup to prevent X from winning after O has already won and vice versa.
7 - You will need some form of output to indicate when and who won. A typical DO card will have either 8 or 16 channels. Build some light flashing logic. You can reset the game automatically when all balls are removed. I.e. RESET = not A1B and not A2B and not .... Then the flashing stops. Another latch: when the first ball is detected, clear the 'won' light.
8 - Build in an 'invalid move' detector. Count the number of white and of black balls. If either has more than one in excess of the other, an 'error' light flashes. The flashing stops when the error is corrected by adding or removing the correct number of balls
9 - Even more fanciness: Build a counter to count who won how many times. It will need a reset. It will also need some form of display. Numeric displays capable of direct connection to PLC DOs exist. You will need to flash or something to indicate overflow.
10 - NOW build a unit that will play against a person. I've seen it built with relays so it should not be too hard. You will need a single set of 9 inputs but 18 outputs to indicate status.
Walter.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I agree with Walt on using microswitch to indicate A BALL is in hole and conductive and non-conductive balls to be an X or O, with logic something like: HOLE SW + NON-CONDUCTIVE BALL = X HOLE SW + CONDUCTIVE BALL = O
HOLE SW -----| |------------------------------------ A X = A and NOT B | BALL CONTACTS | ------| |-------------------- B O = A and B
Don't Care = NOT A
If cost is a factor, then the multiplexing would allow using a very low cost nano PLC: 3 outputs for columns 6 inputs for A & B switches for rows 2 outputs, one each for X wins and one for O wins Total I/O = 5 outputs and 6 inputs
NOTE: Remove ALL the balls to reset the unit.
I would design this around a microcontroller if it were to be a game product.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
mindspringnews wrote:

Conductive balls will have longevity problems, but it's an exercise, right? You could use white and black balls, with a reflective light sensor, but you'd then spend all your time on that and never get any farther...

Hearty agreement here -- but as a vehicle to learn PLC programming it's a good idea.

--

Tim Wescott
Wescott Design Services
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ah schucks, why bother with detecting X or O balls.
First ball is ALLWAYS X, next ball is O, repeat until winner or that all holes are full.
Bonus, programming challenge: How early can you detect a "cats game"?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Yes, eliminate 3 of 6 row inputs for the scanned multiplexed version and only need microswitch or contacts in holes. Flash the X or O winner lamp to indicate next player and ON SOLID for a winner or BOTH ON SOLID for the CAT.

to
to
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
It's when control systems make assumptions that they get lost. You have to have feedback.
Walter.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Very true, so SHOULD distinguish if NO, X or O ball in the hole. Similar to trying to use a software FIFO to detect / track what has been done to or test results for each item in what SHOULD be a sequential production line operation. Without serialization / positive ID of item or it's carrier things will get out of sequence somehow, like someone grabs a part, line jams, limit switch misses or power failure.

all
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
True, in my defense.. its only a simple game.. A little comunication might help the "human" processors to do the right thing.. quickly flash an "X turn' or "O turn" indicator light... ???

all
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

..
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I'm not familiar with that term.
Walter.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
In a TIE GAME = CAT WINS or cats game. Not sure why called that?

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
http://www.keyence.com/products/program/kv/kv.html?links=9:M:T

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I haven't read all the responses; but it looks to me like everybody's trying to use the balls and sensors to identify the difference between an X and an O. The game could be simplified quite a bit if each sensor was just an on/off type, and if the balls were all the same. The way to do that would be with a single switch, separate from the board, to indicate which player was currently rolling his ball.
When it's X's turn to roll, he turns the selector to "X", closing the selector contact. When it's O's turn, he selects "O", and opens the selector contact. If the squares on the board are inputs 1 to 9, and if the player select switch is input zero, then square number one could be read as follows: (X is an input, Y is an output)
X0 X1 Y1 -----] [----] [------( )--- X has a ball in square #1
X0 X1 Y11 -----]/[----] [------( )--- O has a ball in square #1
The conditions for identifying a win can probably be done by more elegant means; but brute force isn't too awful, in this case. A sequence of tests for combinations of inputs, such as Y1 + Y2 +Y3 (X wins across the top row) would be easy to program, especially since many of the combinations are redundant, and could be excluded from the test sequence. Y3 + Y2 + Y1 is also an X win across the top row.
To provide visual input to the players, of course, X and O balls could be different colors; but the color, weight, conductivity, etc., would make no difference to the PLC, as long as the balls can trigger the sensors.
KG __ I'm sick of spam. The 2 in my address doesn't belong there.
Jeremy wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
The game could be simplified even more by making Xs and Os on a piece of scrap paper.
By-the-way, how is your logic going to remember which ball was whose once the next player throws the switch?
Walter.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Go to beach and use fingers in sand ... lol

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Walter Driedger wrote:

I didn't invent the project. I was just trying to help. Besides, don't we all have fond memories of sitting in the back seats of our parents' cars during long summer vacation drives, and overcomming boredom by hauling out the ol' PLC and challenging our kid sisters to games of tic tac toe?
And as far as remembering which ball was which... Uh... well...
I sorta forgot about that.
The outputs would either have to be latched types, if the PLC in question had that capability, or they'd be programmed as latches, as shown in the new, improved version of my suggestion, below. In either case there'd be one additonal input, like a momentary pushbutton, to reset the game. And, I suppose there'd need to be some extra code to exlude X from a square, if O already owned it, and vise versa.
The trouble with shooting from the hip, of course, is that every project or problem looks easier than it really is. Or, if you're a pessimist, you might like the way my friend Ernie puts it: "The more you study something, the more complex it becomes. If you study it enough, it'll eventually become impossible."
X0 X1 Y11 Y1 -----] [----] [----]/[----( )--- X has a ball in square #1 | only if O doesn't already Y1 RST | own the square -----] [----]/[--------|
X0 X1 Y1 Y11 -----]/[----] [----]/[----( )--- O has a ball in square #1 | only if X doesn't already Y11 RST | own the square -----] [----]/[--------|
KG __ I'm sick of spam. The 2 in my address doesn't belong there.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
In fact, this one gets a bit more complica... uh... interesting, every time I look at it. In the most recent revision, there'd be a problem if somebody pressed the reset button before removing all the balls from the game board. If the button was pressed with balls still in the holes, then the PLC would assign them all to a single player, depending on where the selector switch was set at that moment. Or maybe it would assign them based on the order of the rungs in the ladder. Or maybe it would go completely crazy, if someone held the reset button while moving the selector switch, or...
Well, like I said, I didn't invent the project.
All these new problems could be solved simply by testing for all holes empty before allowing reset to happen. But then, of course, there'd be some more programming to do, and probably more bugs to fix.
I think I'm going to quit looking at this one, before it gets complex enough to spoil my whole day.
KG
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
What if the condition of all balls removed caused a one shot game reset, as was suggested earlier, eliminates the need for a reset button circuit.
We must also remember the details of the original posting, constraints:
Balls are ROLLED into holes by the players. To be fair then the weight, size and surface of X or O need to be the same. First thing this suggests, for positive X or O id, would be colored balls and color detecting eyes / sensors, which are not LOW COST. Maybe conductive balls and 2 opposite contact points in each hole, where X and O are the same except for their resistance and then use 3x3 column / row scanning to 3 each A/D row voltage divider or current inputs. Which is cheaper, a PLC w/ 3 A/D inputs or 9 color detecting eyes / sensors? Seen low cost PLC's w/ 1 or 2 A/D inputs or could do a sub scan of 3 rows to one A/D input during each column. Anyone know of a NANO PLC w/ A/D input?
Low cost and using a PLC. I been thinking NANO < $ 250.

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.