Inherited Code and ideas:
My involvement with the CCR began in the spring semester of 2000. Laura Weiland and I brainstormed many different approaches to beginning a train operating system. The code we inherited had its strong points. The previous group who had worked on the train designed a program using Visual Basic 6.0 to run the trains around the track. A user could control the trains and the turnouts through the computer and view a visual representation of the track that highlighted photocells as a train passed. Mark Sternig and Dr. Pankratz wrote one of the major contributions of this group. Together they wrote a library file (dp.lib) and a dynamically linked library file (ccr.dll) which was able to open the peek and poke ports and read the status of the turnouts and photocells. These base functions also provided means to toggle a turnout and finally to close the ports. These files used in my code. Note I include ccr.h and dp.lib to call functions implemented in ccr.dll.
Although this previous semester did get the trains to move around the track after viewing the code, it was recognized that it had major flaws and design issues. The Visual Basic Code used an Access Database to keep track of a train’s direction, speed, and id number. Thus, for each call to change the characteristics of a train calls to a database needed to be made. This process could be slow and given the size of the track, it did not need to be in a database. Furthermore, the group used many global variables to keep track of its data. For example, they used a global variable to keep track of a queue’s head pointer. This left open many issues of data security.
The original idea for an operating system allocated both photocells and turnouts. Arrays were used to keep track whether covering a photocell going a certain direction was either an arrival or departure. Given this, the algorithm could keep track of which turnouts were "locked" and which the user could still toggle. Given the direction of the train around the track, arrays were used to look up what section of track and turnout needed to be allocated or unallocated. Trains that were allocated resources were kept track of in two arrays. One array was filled with zeros or the train’s id that owned that section of track. The other array kept track of turnouts and similarly was number zero if the resource was not allocated or numbered the id of the train that owned it. The major differences between this algorithm and the one designed this year lie in two areas. First, this past algorithm physically numbered new sections of track. These sections of track usually lied between two photocells, but also extended beyond that to into critical parts of the track were turnouts were located. Photocell six never going to be used to allocate resources, but rather to change the toggle the train’s direction around the track. I began to implement this design in Visual Basic code. The code listing for the beginnings of this code implementation are posted on my website. In programming this I found too many exceptions. The design did not necessarily match the actual hardware of the track. However, many data structures from this design would carry over to the new design. The main difference was the difference was the transition from allocating sections of track to photocells. This created the idea for the TrackList data type and simplified the algorithms for updating resources. I decided to discard the original design and code about eight weeks into the semester and start with a new design and to write in C++.