AUTOMATIC CAB CONTROL (ACC) ON THE

TETON SHORT LINE

Wayne Roderick, 3rd Division, PNR, NMRA (life)

05/20/98 rev 01/15/07

Automatic Cab Control (ACC) has been replaced with the NMRA standard Digital Cab Control (DCC). I retain this page for those who still are interested in computer managed control schemes. It served the TSL very well since 1972 and there is much to be said for it.

The cab control system that we will describe here is one of two major sub-systems of the the Teton Short Line train control system. CONTROL SYSTEM. Here, we describe the nuts and bolts (or volts) that make it work. The other sub-system is the Walkaround Cabs.that the engineer uses to control his train.

The term "Cab Control" has traditionally described a system of switchs, or switching devices intended to keep your train controls, the "CAB", connected to your locomotive in a model railroad where other cabs and locos are also running. If we look back in time to classical electrical publications of Westcott, Mallory and others, you'll find the cab control schemes well documented. We also used banks of switchs in the early days (60's) of the Teton Short Line and quickly became frustrated with it. We didn't run trains, we ran switch panels. Some of the bigger model railroads dedicated a person to the job of "dispatching power" so others could enjoy operating trains.

There had to be a better way and some pioneers before me had tried quite a few tricks to eliminate or minimize the electrical switching. I researched and tried many schemes such as big 5 pole, 23 positon telephone stepping relays and finally came up with a system we called Automatic Cab Control (ACC) in the early 70's. ACC completely eliminated the switchs. A cab was assigned to a locomotive and then about 200 TTL IC chips and a bank of relays kept everything connected as you progressed around the railroad. The system easily accomodated route and direction changes, working flawlessly unless you insisted on running into the other guys block in spite of the warning lights and buzzers. Our ACC remained in service, being upgraded with computer support, until May '98 when it was scrapped for Digital Command Control(DCC). During that period, we also experimented with various command control schemes including home made radio links, CTC-16, Dynatrol and others. Ultimately they were all rejected in order to remain compatible with the rest of our friends in the hobby. For most of that time, the TSL was the only "large" model RR in the area that could accomodate visitors and it was important that we be able to run any loco wired to NMRA S-9 standards.

Why tell about it now? Even with the rapidly growing DCC systems, there are still good arguments for computerized cab control such as Bruce Chubb has been promoting and supporting for many years with his Computer Model Railroad Interface (C-MRI), starting in MR Feb' 85. The logic, boolean algebra, like other mathematics does not deteriorate with time, and while you would not use some of my primitive hardware today, the algorithms, computer interface, and software may help you in building a modern day equivalent. If you're electrically timid, with more money than time, then by all means use Chubb's well documented system, otherwise we'll take you on a tour of the Teton Short Lines newest obsolete system, :) to stimulate your thinking.


EVOLUTION

1972-73 TSL ACC system was designed and implemented on sixteen blocks with four cabs using about 200 TTL logic chips and home-wound relays. Logic was cheap, but relays priced for the hobby market did not exist and the industrial stuff was prohibitively expensive. The solution was to buy military surplus and rewind them. We still use those relays today for other purposes.

74/01/16 Writeup of the TSL ACC submitted to NMRA bulletin

74/06/22 Postitive and generous critique on TSL ACC draft by Paul Mallery to make a better manuscript. By this time, I had lost interest in publishing it, and was off into other projects. After the experience of my earlier article on Signalling, (MR-6/72) that generated so much mail and tied up my precious hobby time, I must admit that I was too selfish to commit the time and effort that is required of those that share their work. Appreciate them!!

77/03/-- John Lukesh built a version adapting it to readily available parts and published it in 17 pages of the NMRA Bulletin.

83/06/26 The TTL logic was replaced with a Motorola 6800 microprocessor, while keeping the I/O circuitry that interfaced the railroad data and relays to the 5-volt TTL levels. The "computer" had 4k of memory, and the machine code was painstaking entered by hand. Had a battery for "uninteruptible power".

1984 Installed a Heathkit computer with a "disk-drive" (90k Disks cost nearly $5 each!) and CPM, an early DOS, and reimplemented the algorithm to take advantage of M-80 BASIC language. We also made the program generic, so it could be used on most any railroad by loading a descriptive file. Unfortunately, I again failed to even attempt to share it. Trying to remedy that now.

86/03/01 As the TSL grew it looked like more blocks would be needed but we found it was simpler to revise the algorithm to permit TWO switchs and four possible routes to exit a block. This way, the ACC blocks continued to be the same as the signalling blocks. There has been no significant change to the ACC since 1986, other than computer upgrades, and four additional blocks. It has served our Thursday night crew with nearly zero maintenance until May 98 when we scrapped it all.


ORIGINAL ACC SYSTEM

We'll not attempt to document that. John Lukesh done a good job in the NMRA Bulletin in March 77.

COMPUTERIZED ACC

The TSL computer has evolved to accomplish many tasks and we won't delve far into the computer in this section on ACC. ACC occupies only a very small part of the 100k compiled QBASIC program. Let's get started.

The first and obvious thing we need is to have your track cut into electrical sections that we will call blocks. The block boundrys may or may not be the same that you use for signalling- On the TSL, they are the same. Very careful planning is involved here. You keep the blocks short for flexibility but it costs more, or make them longer to reduce expense. I use a block for each siding and another for its parallel main. Two more blocks between sidings work well for us. At Malfunction Junction (MFJ), two blocks serve, each extending out to the Yard Limits. The boundry between the two yard blocks float according to the turnout settings on both ends of the yard allowing us to simultaneously handle arriving and departing trains without increasing the block count. (need link to MFJ). The interior yard tracks of MFJ are not in the ACC system.

An array of relays is constructed that can connect any block to any cab. There is no need for an open or non-connection. The block can be left connected to the last cab that used it. Our home-wound relays were assembled on plug in cards with the TTL interface and rack mounted along with other components of the system. There are those that will argue for solid-state switching- That's fine and we considered it more than once, but what might you want to send thru that solid state device next year when the newest gadget comes out?

With the relay array built, we can proceed to the algorithm that decides what relays to energize.

As we develope the necessary logic, two viewpoints might be considered. One would be related to the cab, and we would sit in the cab with logic devices capable of connecting us to any block. An example might be a stepping switch for each cab with many positions that could connect to any block as we progress down the track. The second viewpoint would have us stand along the wayside watching the traffic go by. We would build circuitry (and software) for each block and examine the cabs that request the use of the block, and thats the way we do it. Our system is "block oriented".

First we need to examine the TSL algorithm for keeping your cab connected to your loco. Our blocks can contain two diverging routes meaning that when in the block, we may have up to four choices of where to go i.e. forward or backward on the "main" or one of the two diverging routes. With our algorithm, each of the switchs is described with three binary bits making the railroad data very generic. The actual processing code is brief, because most blocks are treated the same. Remember, this was written in the days when memory was costly and code was hand entered. The BASIC program simply put words where machine or assembly language used to be.

For each block, we need to know:

ONE: Description of the turnouts that exist between our current block and the adjoining block(s). i.e. facing/trailing and the block number that they connect to, as well as the current setting- normal OR reverse.

TWO: Is the block occupied? We need an occupancy detector that can also be used for signalling and panel displays if desired.

For each cab, we need to know:

ONE: What direction does the cab have selected. Originally, we looked at track polarity and interfaced it to 5 volt TTL, later the info was drawn from our MUX Cabs.

This is all we need to know to implement a highly successful automated cab control system. You need to get this electrical information into 5 volt logic level signals and input it to the computer.

The software does this once after startup:

Reads in a Block Specifications data file that describe each block and its relationship with adjacent blocks including the turnout number(s), location and class, facing or trailing.

The software does this each cycle:

With each computer cycle (ours does seven cycles/second), the switch positions, occupancy detectors and cab direction switch settings are read in. Also, the dispatchers INITIATE block and cab switchs are read.

For each block, the software will determine if it's occupied. If it is NOT occupied, then no further action is taken on that block.

If the block is occupied, AND the direction switch is set AND the turnout(s) are properly aligned, THEN we have a VALID REQUEST to another block- one of a possible four.

If the REQUESTed block is unoccupied AND NOT already committed to another approaching train, THEN the ASSIGNment is made and the appropriate relay(s) are activated.

IF the valid REQUEST is denied THEN an alert message (light and sound) is sent to the requesting cab.

The REQUEST and resulting ASSIGNment if made, remain as long as the direction switch is set to approach the REQUESTed block and the turnouts remain aligned. This is the priority system. "First valid request gets it" The ASSIGNment can be overridden with the dispatchers INITIATE switch(s) to get things started.

After the train leaves a block and the occupancy detector shows the block as unoccupied, what happens? Why nothing of course! Why disconnect it? I haven't found a good reason in over 25 years although some other designers seem to do that. The block is still connected to the last train, but it IS available for reassignment.

You can see that the logic is simply a few AND/OR/IF THEN statements that apply to every block on the simplest or largest railroad. And that's all there is to it!

Mechanical layout:

The original ACC system was constructed on a group of 20 pin circuit cards plugging into a card frame that was obtained on the surplus market. The cards contained discrete components and rows of solder eyelets, so that we could strip them and re-use them. The 20 pin limit was frequently aggravating, but they were rugged enough to carry track current. Some of those cards have been through several generations of re-use. The card frames along with other devices were mounted on a homemade "standard" 19" rack system that swings out from under the layout to a carpeted area and then opens like pages of a book for easy access to both sides of two racks. Later, when the handwired 6800 computer came along, a frame holding eight 44 pin cards was added with handwired perf'cards from Radio Shack. Finally, the guts of a conventional PC complete with a floppy and hard drive was mounted in the rear rack, but that's another story.


Some supporting documents from our musty old files:

THROTTLE & DIRECTION CONTROL SYSTEM. A 13k (.GIF) file that shows how the ACC relays fit into the overall system. Three SPDT (form C) relays serve four cabs.

ACC LOGIC ALGORITHM. A text file that you can print out.

ACCPORT INTERFACE CARD. This card is a custom, handwired card that plugs into one of the ISA sockets on PC XT or x86 mother board. It is connected to the ACC ADAPTER CARD with a 25 wire ribbon cable. 16k (.GIF).

ACC ADAPTER CARD. This card replaced the original 6800 microprocessor card and extended the I/O functions to the PC with a 25 wire ribbon cable. 14k (.GIF).

ucwira2.txt A text "drawing" of a typical output card to drive the relays. Three of these cards drove 90 relays or other devices such as DENIAL warning lamps.

ucwira5.txt A text "drawing" of a typical data input card used to input turnout positions, cab directions and the dispatchers INITIATE switch. It is incomplete, because some connections and logic symbols (7400 & 7404) were added by hand, but you'll get the idea.

BLOCK SPECIFICATIONS. A text file that initially loads with the operating program to describe the relation of each block with those around it. The file also contains "pictorial text" that is not loaded but is intended as helpful comments when we look at it later.

QBASIC CODE Excerpts from the TSL operating program, before DCC was integrated. Vintage 1995.

(.GIF) files listed above were converted from high resolution AutoCad vector drawings in the (.DWG) format. e-mail us if you have use for them.


GOODBY ACC :( IT WAS FUN

I certainly do not intend this as a construction article or a way-to-doit, so there are many holes in the data, but as we rip out the 25 years of TSL ACC in favor of DCC, I sincerely hope you can glean some info from our leavings and again I apologize for failing to share in the past. The 'net makes it so easy for us special interest nerds to share, there is no longer any excuses. I love it! SHARE!

Return to Teton Short Line Home Page