|
|
|
|
This system allowed a user to toggle turnouts,
control trains, and send commands manually |
|
Used an Access Database to keep track of train’s
direction, speed, headlight, and taillight. |
|
Could record and playback track, but used timers
to calculate time between toggling a turnout. |
|
One set of train controls controlled all trains. |
|
Less data protection |
|
Did not stop Trains from collision |
|
Inherited Ccr.dll written by Mark Sternig and
Dr. Pankratz |
|
|
|
|
|
|
Labeled actual sections of track |
|
Functions for next photocell and turnout in four
array structures for clockwise, counterclockwise, straight, and curved
turnouts |
|
Functions to tell if photocell was arrival or
departure |
|
Overall, Too many exceptions |
|
|
|
|
A user creates an event by clicking a button or
pressing a key on the keyboard |
|
The user screen handles the event by using the
resource manager it created. |
|
The resource manager calls the System Board
functions in the ccr.dll to toggle a turnout |
|
Or calls a train’s method that will update train
data and call motor or function commands located in dcc.dll |
|
|
|
|
Timer in the Resource Manger is fired every half
second |
|
Two arrays keep track the current status of the
photocells and the previous status of the photocells |
|
When these two arrays differ we need to handle
an arrival or a departure of a train. |
|
On an arrival the system finds and if possible
allocates new resources to a train. |
|
On a departure the system frees resources no
longer needed by the train. |
|
|
|
|
Train object provides both data and function storage |
|
Command in train data type updates data and
calls dcc.dll functions to send the dcc commands to the trains on the track |
|
|
|
|
|
|
Represents a graph through an array of linked
list. |
|
Two TrackLists, one for clockwise movement and
one for counterclockwise movement provides a function to output the next
photocell and turnout |
|
Gives both the next turnout and the direction
that turnout needs to be in to reach the next photocell given. |
|
Can be read from a file for different tracks. |
|
|
|
|
Array that keeps track of which photocells are
owned by which trains |
|
On initialization array is filled with zeros
representing that no trains are on the track. |
|
When resource Manager adds train the photocell
manager is filled according to where the trains are going to start. |
|
When photocells are covered by a train the
photocell manager uses the train’s id to fill the array |
|
|
|
|
An array of integers that keep track of which
turnouts are owned by which trains |
|
Initialized to an array of zeroes which
represents that no trains own any turnouts |
|
When trains are added resource manager fills
array in turnout’s number with train’s id number |
|
When a train covers and uncovers photocells it
the turnout manager is updated to represent the new allocations. |
|
|
|
|
|
|
The Train List allows the Resource Manager to
keep track of which trains are blocked and which trains are active. |
|
Trains are switched between lists when needed
resources are being used by another train and when those resources become
available |
|
All user commands search the active train
list. Commands sent to blocked
trains are ignored by the resource manager |
|
When put on the blocked list speed is set to
zero, when moved to active list speed reset to the last speed that the user
issued |
|
|
|
|
|
|
|
|
Used a Top down design and a bottom up
implementation |
|
Started with simulation of events through
keyboard an then implemented system with existing track layout |
|
Design…Update… Update again |
|
|
|
|
|
|
The future of the train involves more batch file
processing. |
|
A larger and more complex track layout will
provide more testing |
|
Networking with live feed of video where Train
control is client and User Screen becomes the server |
|
|
|
|
Design, Design, and Design some more |
|
Do not be afraid to start over if a new and
better design is found. |
|
Do not let the size of the project intimidate. |
|