From: utzoo!decvax!harpo!npoiv!alice!mhtsa!allegra!psuvax!burdvax!lime!we13!otuxa!ll1!ihldt!jhh
Newsgroups: net.railroad
Title: Re: Computerized railroad
Article-I.D.: ihldt.1118
Posted: Thu Nov 11 11:15:59 1982
Received: Fri Nov 12 10:43:27 1982

References: rocheste.212

While at U. of Michigan, I took a course whose last project
required writing a program to control a train on an N-gauge
railroad.  Each block could be powered separately via a D/A
arrangement.  At the entrance to each block were photocells
under the track which detected the darkness of a train and
triggered an interrupt.  Each switch was also under software
control.  Several `throttle controls' were available which
had a switch and a potentiometer.  The pot was fed into
an A/D from which the speed was to be controlled.  Whenever
the pot or switch changed positions, an interrupt was generated.

>From this hardware, the project was to get the train to
respond to the pot for speed/direction control, and the
switch was used for controlling the position of the next
track switch.  Whenever the train left a block, that track
was to be powered down.  Any switch approached from the top
of the Y had to be moved to the correct direction.

For extra credit, multiple trains could be controlled.  This
required collision detection and avoidance plus
dermining which photocell interrupt was associated with which
train.  Other extra credit problems included route selection
and speed control on curves.

There were several problems with this railroad.  One was that
if a light was burned out, or the lights were turned out,
no photocell detection could be done.  Another problem was
that if a second photocell interrupt occurred before
the first one was processed, the second was lost.  Another
less severe problem was that the compiler used was very
inefficient and filled the 24K very quickly.  The language
used was CRASH (unknown acronym), under the OSWIT (Operating
System WIth Trains).

			John Haller