My Modeling Goals

I recently was a guest operator on an operations oriented layout that used a C/MRI interface to manage the movement of trains via signaling and route selection. I have operated many layouts over the years and was very impressed with the prototypical operation. It's not surprising to learn the layout is owned by a railroad dispatcher. That visit made me realize that my traffic management and routing system was not only feasible, but not that difficult to make a reality.

I am interested in modeling the PRR's Panhandle Division in the late 1960's between the west portal of Gould tunnel near Mingo Jct. and just west of Frazeysburg, Ohio in the 1960's, a distance of 96 miles. There were 7 towers and 12 remote controlled locations plus numerous distant signals between those points. My "big plan" layout would have 4 towers and 6 remote controlled locations and distant signals as required between the interlockers. Each tower location would have a scaled down US&S styled panel to control the crossovers, sidings, and signals within that tower's segment of remote control and local appliances.

The N scale testbed layout represents 1 tower and the 3 locations it remote controlled (Morgan Run, Wally [WV], and Clow). Current sensing block detection is probably the easiest to implement, so i would have to chop the layout into blocks, which should prove rather easy since it's only 8'x5'. I intend to switch to metal wheels, so i could make the system foolproof by adding a resistor to each car to get accurate block detection.

The tower system eliminates the need for a dedicated dispatcher and puts control of the layout in the hands of the train operators - this makes 1,2, or 3 person operating sessions much less complicated. The biggest pitfall is not having a single person acting as the dispatcher governing all movements on the layout, but with a 2 track main and several sidings, I don't think it will lead to a mega-merger sized meltdown if several trains need to access the same location at once.

Each train operator would have to co-ordinate movements with the trains in advance and behind them - basically becoming the tower operator when their train is within a tower controlled segment. The problem of "pacing" could cause problems - if a train crew performs it's work at a given location rather quickly it could gridlock the layout by moving all the action to one area. I haven't quite worked out all the operations aspect of using tower control with "self governing" but with good operators and lots of communication and a few runs of the layout, it might prove a rather "lightweight" operating session system.