robotics final project report

18
Final Project: Automated, Multifunctional Score Counter for Tabletop Games Report and Project by Andrew Kocur Instructor: Dr. Kevin McDermott IE 455-003: Robotics and Programmable Logic Controllers Fall 2014

Upload: andrew-kocur

Post on 25-Jan-2017

25 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Robotics Final Project Report

Final Project: Automated, Multifunctional Score

Counter for Tabletop Games

Report and Project by Andrew Kocur Instructor: Dr. Kevin McDermottIE 455-003: Robotics and Programmable

Logic ControllersFall 2014

Submitted: December 5, 2014

Page 2: Robotics Final Project Report

Table of ContentsExperimental Discussion..............................................................................................................................2

Components and Specifications..................................................................................................................3

Layout and Sequence of Events...................................................................................................................5

Mode A: Standard Rules..........................................................................................................................6

Mode B: 2-Point Lead Requirement with “Tiebreaker” Subroutine........................................................9

Advantages and Ways to Improve.............................................................................................................13

Potential Improvements........................................................................................................................13

Page 3: Robotics Final Project Report

Experimental Discussion

The seven-segment display is a simple, cost-effective way of depicting the 10 Arabic roman numerals used by nearly every country in the world. Though conceptualized decades earlier, the invention of the Light Emitting Diode (LED) led to the widespread proliferation of these devices by making them simultaneously cheap, small, and efficient for their purpose. Shortly after their creation, the seven-segment LED could be seen used everywhere from scoreboards for professional sports and sensitive scientific instruments to children’s toys. And although much more advanced methods of displaying characters have been developed since, the seven-segment display still remains in widespread use due to this simplicity and cost.

It is this use in game boards and similar applications that led to this project; an attempt to recreate the automated scoreboards featured on many types of tabletop games; such as foosball or air hockey. In these scoreboards, the series of lights contained within these LED systems are changed into the different patterns required to display the digits 0-9 and a small selection of other symbols using a limited number of inputs, often a single one outside of the power switch.

In this way the purpose of this project was to recreate the basic programming for one of these scoreboards, and hopefully expand upon the most basic one a little bit. In this way one could learn exactly how this ubiquitous piece of electronics is programmed to function with other electronics and parts of modern technology, and attain a small grasp on how multiple outputs can be controlled using a relatively small number of inputs, which can easily be seen to have multiple applications outside of the use of segmented displays for programming.

With this in mind, the goal of the project was twofold; first to learn how to manipulate a single 7-segment display. After obtaining an understanding of how to program the first display, the second part was to learn how to manipulate both displays simultaneously and in relation to each other.

Andrew Kocur 3

Page 4: Robotics Final Project Report

Components and SpecificationsThe primary component of the project would naturally be the Programmable Logic Controller

used to receive and send the energize/de-energize signals to the inputs and outputs involved. The controller used in this instance was from the Allen-Bradley SLC 500 series of modular PLCs. This particular system had five total modules installed. The first and most important component of the PLD would be the 1747-SLC 5/04 processor module, with 16k available onboard memory.

Figure 1: Left to Right: 1747 SLC 5/04 CPU, 1746 IB16 Input Module, 1746 OB16 Output Module

The second and third modules installed were a pair of Allen-Bradley 1746-IB16 Input Modules, which would be used to receive and relay signals coming from the attached inputs. However, as only four inputs were used in the project, the second input module remained unused.

Lastly, the final two components attached to the SLC 500 system were a pair of Allen-Bradley 1746-OB16 output modules, both of which were used to regulate the outputs of the projects.

In order to program the SLC5/04 CPU, SLC 500 system was interfaced with a standard PC running Window XP. Installed on this PC was a version of RSLogix 500, proprietary software developed by Rockwell Automation (the parent company that owns the Allen-Bradley name) specifically for interfacing and programming their software.

Andrew Kocur 4

Page 5: Robotics Final Project Report

The inputs attached to the SLC 500 system were as follows:

One (1) Single Pole, Double Throw (SPDT) switch with a center-off mode. This switch was used to control the power state of the entire counter system, addition to being used to manage the mode selection of the system. Setting it to one side activated one of its two play modes, while setting the switch to center energized neither modes and left the system in an off state.

Two (2) normal microswitches with metal tabs attached. These switches kept track of the score for the left and right players, respectively, and if mounted to a working game would have been set up in such a way to be triggered every time someone scored a point.

The outputs attached to the SLC 500 System were as follows:

Seven (7) red 12-Volt DC lamps. These lamps were arranged in a figure-eight pattern in order to mimic the functionality of a seven –segment LED display, which is typically to display the 10 Arabic numerals (0-9) and a limited number of other symbols.

Seven (7) green 12-Volt DC lamps. As with the red lamps, these were arranged to simulate the functionality of a seven-segment LED display, but for the other player.

Three (3) amber 12-Volt DC lamps. One each of these lamps were wired to activate whenever the player on its respective side reached a high enough score to win. The third was wired to activate only when the conditions for a tiebreaker were met in the system’s “B” mode, and to stay active until a winner was decided.

One (1) audio buzzer. This was programmed to sound off for one second whenever either player won the game. Additionally, it sounds off for three seconds whenever the “tiebreak” condition is met in the game’s “B” mode.

Figure 5: Audio BuzzerFigure 4: Red, Green, and Amber 12VDC Lamps

Figure 2: MicroswitchFigure 3: SPDT Switch and Diagram

Figure 6: Left and Right 7-Segment Array Setups, with Win Indicator Lights

Page 6: Robotics Final Project Report

Layout and Sequence of Events

Figure 7: Scoreboard Display Model Diagram

The program for this setup consisted of two main modes, each of which share a lot of the same programming. They will each be explained in two separate subsections, with the simpler “Mode A” first in order to explain the basics first.

Andrew Kocur 6

Page 7: Robotics Final Project Report

Mode A: Standard RulesMode A is a relatively straightforward “First to ten points win” mode. When first activated, the

left and right 7-segment arrays light up in a pattern to display the numeral “0”. Each time a microswitch is pressed and activated, the system registers that the appropriate player has scored a point, and the array of lights changes its state in order to display the number of times the switch has been pressed, and in turn how many times that player has scored. After either microswitch has been activated 10 times, three things happen simultaneously;

The buzzer activates and sounds off for one second to indicate a player has won; The amber “WIN” light activates on the side of whichever player scored 10 and won; All lights on both of the character displays deactivate.

Figure 8: Sample Score Counter Line: Counter C5:1

Each lamp array responds to a series of 10 counters (C5:1-C5:10 for the left array, C5:11-C5:20 for the right array), which in turn all respond to the same input (the right scoring microswitch for the P1 array, and the left switch for the P2 array, respectively). Although they all record the activation of the same input, they each have a different activation preset number (Counter C5:1 has a preset of 1, C5:2 has a preset of 2, etc. All the way up to C5:10 with a preset of 10). Each time a player scores, the microswitch for the appropriate side is turned on, which increases the accumulation value for all counters for the player that scores. When a counter’s accumulation value becomes equal to or greater than that of its preset value, the “done” (DN) sub-address within the counter goes from off to on (example: the DONE bit sub-address for counter C5:1 would be “C5:1/DN”).

These DN bit sub-addresses are in turn used to control the on/off states of the 12VDC lamps in

the 7-segment character displays. The DN bit address associated with a certain counter (and in turn a certain player score) are assigned to the line of every light in the array that requires a change of state in order to display the appropriate numerical digit at that count. Depending on that light’s previous state,

Andrew Kocur 7

Figure 9 Sample Segmented Array Light Ladder Line: Light 1B

Page 8: Robotics Final Project Report

this may require either a NOT gate with that address that opens when the appropriate counter reaches the “done” state, or a normal gate on a branching, parallel line that re-energizes the lamp output when the light once again needs to be turned on.

For further clarification, the activation/deactivations of a single lamp within an array will be tracked, from a count of zero to a winning count of 10. The lamp chosen to demonstrate is the left-top lamp of the left array, labeled “Light 1B”. The ladder line for this lamp is partially displayed below:

Figure 10: Truncated Light 1B Ladder Line, with Starting State Array

As can be seen from the above figure, the line for Light 1B has four different gate addresses linked to the DN state of the counters, arranged on three parallel lines. This means a total of four different state changes for light 1B as the array counts up from 1 to 10.

0. Default value displayed upon first turning on the system. Light 1B is on by default, as it is required to display digit “0”.

1. Counter C5:1 reaches its preset and its DN state activates. There is a NOT gate with the address for C5:1/DN on 1B’s line, which activates and opens, turning off light 1B.

2. Counter C5:2 reaches its preset and its DN state activates. Light 1B needs to remain off in order to display the digit two, so Light 1B has no gates associated with its address and remains inactive.

3. Counter C5:3 reaches its preset and its DN state activates. Once again, Light 1B does not need to change state and does not respond to counter C5:3’s change of state.

4. Counter C5:4 reaches its preset and its DN state activates. Light 1B is needed to properly display the player’s score of 4, so a normal gate with the C5:4/DN address is activated and closes on a branching line in parallel with the C5:1/DN NOT gate, closing the circuit once again and activating Light 1B.

5. Counter C5:5 reaches its preset and its DN state activates. Light 1B is required to display the score of 5, and has no gate on its line which responds to counter C5:5’s state change.

6. Counter C5:6 reaches its preset and its DN state activates. Light 1B is required to display the score of 6, and has no gate on its line which responds to counter C5:6’s state change.

7. Counter C5:7 reaches its preset and its DN state activates. Light 1B is not required to display the digit of 7, and since it was active for the two previous scores, requires a state change. A NOT gate with the address C5:7/DN is placed on the line in series with the gate currently keeping it active, C5:4/DN. C5:7/DN is activated an opens the circuit again, deactivating Light 1B.

Page 9: Robotics Final Project Report

8. Counter C5:8 reaches its preset and its DN state activates. Since C5:7/DN deactivated light 1B one score prior, normal gate C5:8/DN is placed on another branching parallel patch with lines C5:1/DN and (C5:4/DN)*(C5:7/DN). This closes the line once again, reactivating Light 1B.

9. Counter C5:9 reaches its preset and its DN state activates. As Light 1B is needed to display a score of 9, the line for Light 1B does not respond to the counter C5:9’s change of state.

10. Counter C5:10 reaches its preset and its DN state activates. This is the “winning” score for this mode, and because of this, the C5:10/DN bit in turn triggers a latched memory bit B3:1/0. This bit has a NOT gate with its address on the main line for every lamp in both players’ score displays. This deactivates all array lamps, Light 1B included. No lamps will respond to any additional inputs until the system is turned off again, which unlatches all latched bits and resets all counters to their default values

The rest of the lights for the P1 display, in addition to all of the lights for the P2 display, are programmed in a similar manner. A full binary logic chart for the P1 display is given below.

LED Segment Display Logic Chart (P1 Display):Character Displayed

0 1 2 3 4 5 6 7 8 9 A -

1A 0 0 1 1 1 1 1 0 1 1 1 1

1B 1 0 0 0 1 1 1 0 1 1 1 01C 1 0 1 1 0 1 1 1 1 1 1 01D 1 1 1 1 1 0 0 1 1 1 1 01E 1 0 1 0 0 0 1 0 1 0 1 01F 1 0 1 1 0 1 1 0 1 1 0 01G 1 1 0 1 1 1 1 1 1 1 1 0

Digital Display

Page 10: Robotics Final Project Report

Mode B: 2-Point Lead Requirement with “Tiebreaker” Subroutine Mode B uses much of the same programming as Mode A; in fact the counters and ladder lines

used to count from 0-9 in Mode A are the exact same ones used to count from 0-3 in Mode B, and could continue to count up to 9 if not for the additional subroutines activated in Mode B not present in Mode A.

The most relevant of these lines are the 3 depicted above. These lines feature a total of four comparison function modules on three lines. Comparison functions are capable of comparing a

numerical value stored at an address within the memory of the PLC to either a value stored at another

address, or a constant value if the programmer so desires it (which is what has been done for all four of these functions). When the criteria set by the comparator is met, the part of the line it lies on is closed and activated. The comparators used in this particular program all happen to be EQUAL comparators, which means their activation criteria is met only when the two values being compared are equal to each other.

Much like how the counters in this program have sub-addresses for the “DONE” state, the counters also have sub-addresses for their “Accumulation” values, which can be referred to by other parts of the program. In this case, the accumulation addresses for counters C5:1 and C5:11 are checked by two comparators each, for different reasons.

The first two comparators on lines 0038 and 0039 check for the standard win condition set by Mode B, which is “win at 4 points”. As the program is currently written, all of the programming for Mode A is still active. This means a player who reaches a score of 10 would activate Mode A’s win condition, even in Mode B. However, while in Mode B, these additional lines are active, and due to the fact that they are constantly checking a single counter’s accumulation value instead of waiting for a DN signal from a specific counter, will always meet their activation criteria before Mode A’s win condition can be met. As it is, the comparators on line 0038 and 0039 check for when the first counters for each player reach an accumulation value of 4. When one of the players do, the respective comparator

Andrew Kocur 10

Figure 11: Mode B Comparator Lines

Page 11: Robotics Final Project Report

activates the Mode B win condition for that player, disabling all further input until the system is shut off, exactly like Mode A.

In addition to the lower win condition threshold, Mode B has one more important feature. On line 0040 pictured above are two EQUAL comparators which check the accumulator values of the same counters as the comparators on lines 0038 and 0039, but in series. In addition, they are each set to activate when the accumulator reaches a value of 3, one lower than the score needed to win. The result of this is a line which does not activate unless both players are one point away from victory. When this condition is met, output memory bit B3:0/0, labeled “Tiebreaker Mode” latches closed, and in turn effectively hijacks the entire program.

When the “Tiebreaker Mode” bit first latches active, four things happen in response:

The memory bit activates a 3-second timer. This timer in turn activates the buzzer at the moment it starts counting using its energize bit address, T4:0/EN. When it finishes counting, its done bit address, T4:0/DN, activates and turns off the buzzer via a NOT gate on the same line as the energize bit address.

The central amber light, labeled “Tiebreaker Alert” activates and stays on until somebody reaches a win condition.

The “Tiebreaker Mode” NOT gate present on every line for every character array light opens, effectively disabling the number counting program set up and explained in Mode A. At the same time a normal gate with the same address on each array light line activates, essentially enabling a new program.

Lines 0045-0052 are latched closed, activating a new set of 4 counters that control the “new program.”

Page 12: Robotics Final Project Report

Figure 12: Tiebreaker Mode Up/Down Counters

These 8 lines control 4 different counters, and significantly change how the displays work. When this new mode is activated, in the 12VDC lamp arrays for each player only have two different patterns; a “-“ and an “A” pattern, with the “A” pattern used to signify “point advantage” by for the player.

Unlike the other counters for Mode A and B, which could only count upwards, these counters also have count down functions. These count down inputs respond to the microswitch opposite of the one that counts up. The end result is that whenever one set of counter counts up, it subtracts from the accumulation value of the other one.

Page 13: Robotics Final Project Report

Figure 13: Tiebreaker Mode Array States

The “Tiebreaker Mode” programming is designed so that a player must score two points in a row in order to win. Instead of using numbers to show this, it used the previously mentioned “-“ and “A” setups. When neither player is ahead of the other in tiebreaker mode, both player’s displays have only the center light active for the “-“ pattern. Whenever a player scores, that person’s display will change to an “A” pattern to signify advantage. However, if the player who does not have an advantage scores, he will remove a point from the first player’s count and add one to his own, returning the scoreboard back to its neutral state. This can continue indefinitely, until one player scores twice in a row, which triggers the win condition light and buzzer as normal.

Page 14: Robotics Final Project Report

Advantages and Ways to ImproveMost of the advantages with the hardware and setup lie within the use of the Allen-Bradley SLC

500 system and RSLogix 500 software over its competitors, as nearly any other part involved could have easily been replaced with a similar substitute. Although notably more costly than its competitors, the SLC 500’s expansion slots allowed for the use of more outputs that would have been possible on the other types of PLCs available, such as the IDEC Microsmart Pentra, which has a hard limit of 12 outputs.

The RSLogix 500 software, although featuring a steeper learning curve compared to IDEC’s WindLDR software, seems to be much more straightforward to use once you understand its terminology and syntax, in addition to being more robust. One particular thing of note possible using RSLogix 500 software that did not seem possible using WindLDR was the ability to use both the activation of a timer and the completion of its count as two separate signals for other parts of the program.

Potential ImprovementsIn terms of ways to improve the program and system, there a very significant amount, most of

which came to light in the tail end of the project as more and more was learned about the functions available within the RSLogix 500 software. Most of these potential improvements revolve around the additional functionality available due to the comparator and mathematical operator functions, which were only learned about and introduced to the program very late.

First, additional use of comparators could have dramatically reduced the usage of counters within the program, to a small handful, as opposed to the 24 used in the program currently. It is fairly likely that the use of a significant number of comparators with a few counters is much less memory-intensive than a significant number of counters. Earlier knowledge of these functions likely could have made the program much more efficient, both CPU and line-wise.

Second, as a result of the mathematical function operators, it is likely with the addition of one or two more input buttons, the stretch goal of having an end-user reprogrammable win score is possible. There is a MOVE logical operator function available within the RSLogix 500 program. The details have not been investigated, but it is apparently possible to change and save values to addresses using inputs while the PLC is in run mode with these operators. Keeping this in mind, one can see how it would certainly seem reasonable enough that it would be possible to figure out how to change the values that the comparators use to check for both the “win” and “tiebreaker” conditions while the program is still running.

Most of the aforementioned improvements were a bit too advanced and time-intensive for the timeframe given to complete the project, but one could easily see how they could be reasonably done given sufficient time and knowledge of the RSLogix 500 software.

Andrew Kocur 14