(I've moved this to jmri-developers, because it's a pretty detailed
discussion, and moved parts of the original post around a bit to make
the reply seem to make some sense)
At 5:12 PM +0000 7/14/04, Mike Yawn wrote:
>I want to use a CTC-type control panel for the dispatcher, to control
>the turnouts and signal aspects. However, my vision of this is the
>dispatcher in the role of a tiebreaker - I'd like to use something
>like the simple signal logic to clear trains automatically as
>frequently as possible, and only have the dispatcher get involved when
>a turnout needs to be changed or congestion requires one train to be
>given right-of-way over another. So if I just want to run a single
>train around the mainline, no dispatcher is needed and the engineer
>should always see green (assuming turnouts are aligned). But as the
>layout gets busier, a dispatcher becomes required at some point, and
>operation begins to resemble the prototype more.
You may end up with several different definitions of the controls for
your layout, and load the one you want when your desires change. I
first saw this on Ed Loizeaux's beautiful S-scale layout. His
signals had four modes IIRC:
*) Completely prototypical, when you wanted it right, and didn't mind
the hassles of timelocks, etc
*) Pretty close, more than close enough for the average modeler
*) "Housewife mode", where they basically operated like traffic lights
*) "Oooh, look at the pretty lights!" mode to show them off
He does this by running different programs; the equivalent would be
different PanelPro files that have CTC logic in them or something
more automatic, for example.
>- so I can get feedback on whether others are interested in the style
>of control I'm trying to model - either others interested in this just
>as described, or ways in which the design could be improved to make it
>useful to as many users as possible.
I'm _definitely_ interested in your work! I first got involved in
this because I wanted to signal my small layout, and didn't have a
way to do it. The layout is now gone, and I don't seem to spend much
time on the new one yet, but the interest is still there.
Let me back up a little and explain two ideas that are very important
to understanding how prototype signalling works, and that I think
will matter to how a more comprehensive approach to JMRI signaling
A) Vital vs CTC circuits
"ABS", block controls, etc are called "vital circuits". That means
they protect life and property, and you cannot mess with them. CTC
on the other hand is _not_ a vital circuit.
This means that a CTC board, or the operator sitting at it, literally
cannot tell a signal to turn green (well, set the signal to clear;
more about that later). Only the vital circuits can do that! But
the CTC machine _can_ tell the vital circuits to hold a signal at red
(actually "stop", as we'll see below) for the purposes at traffic
This is more than a technical point. It's important to understanding
how that whole system worked, both if you want to use it as a
dispatcher and for modeling one.
The existing "simple signal logic" is a simple (e.g. stupid) version
of those vital circuits. It tries not to allow more permissive
signal aspects than safety allows. (The real hardware is of course
very good at this; Simple Signal Logic isn't yet, though Tom Stack is
working hard on that) It gets it right on certain things, like not
being allowed over a turnout thrown against you. For a section of
single track that two trains might enter from opposite ends, there
are varying definitions of "than safety allows" which have lead to
different solutions like ABS, APB, etc. (For more details on these
in the prototype, please see
The prototype vital circuits take this farther. In addition to
controlling the signals, they have a concept of "locking" to prevent
unsafe conditions. For example, they'll "lock" a turnout until it's
safe to move it. That requires that no train be detected over it,
and the signals that protect the turnout be showing stop. If the
signals are still read from long ago, some higher function (e.g. a
CTC panel) can flip the turnout back and forth, no problem.
But what if the signals aren't at stop? Generally, a CTC panel or
other equipment can request that a signal be "dropped to stop" at any
time, and that will happen _immediately_. But that's not enough! A
train could have just passed that signal, and now can't get warning
in time to stop before the turnout that's about to be thrown. Things
like "route locking" (once the turnout is lined and a certain block
occupied, the turnout can't be changed until a series of blocks
becomes unoccupied) and "time locking" (once the turnout is lined
and the signal cleared, there's a fixed delay from the time the
signal is dropped until the turnout unlocks; this is meant to give
the train time to get to the next signal and stop).
Modelers want to have different versions of fidelity to these vital circuits.
CTC then sits on top of those, issuing commands that are more like
"set all the signals there to stop" and "allow the signals eastbound
to clear" than "set the trains eastbound to clear"
B) Aspect vs Appearance
"Aspect" and "Appearance" are two different things on the prototype.
"Green" is an appearance, as is "Green over yellow" and "dark".
"Clear", "Stop", "Diverging Clear" are aspects.
What's the difference? The engineer wants to know the aspect,
because that determines what's going to happen next, and that's the
info that will be used to figure out what to do next: More throttle,
less throttle, jump from the train, etc. The appearance is
secondary, and is effected by _lots_ of other considerations: Can we
afford to put three-head signals everywhere? Do we need to? (e.g.
how many aspects will we show here?)
On the SP, the following are all interpreted as "Clear" in 1996:
Green over dark
Green over dark over dark
Green over red
Green over red over red
White over color-position-green over dark
Any of those indicates "Proceed"
The "Approach" aspect could be shown by 8 different aspects (with
several sub-modifiers, so if you really counted them all it's more
like 24), but means only one thing:
"Proceed prepared to stop at next signal. Trains exceeding
40MPH must begin reduction to 40MPH as soon as
engine passes signal displaying approach."
Personally, I think it's helpful to separate out terminology about
"aspect" vs "appearance" because the appearance is so much affected
by the hardware on the layout. If I only want to
build/buy/install/wire etc single head signals, I'll use a very
simple set of appearances. If I want to model a particular spot in
Ozol, CA on the SP, which had a double track bridge with three-head
signals for each track on each side, plus dwarf and lunar signals,
then the appearances are much more complicated. But the underlying
model logic is just deciding "Well, can I say clear, or should I use
>- I notice the current SSL allows up to four sensors to be watched. I
>could duplicate this behavior, but would like to understand it. In my
>setup I only plan to watch one sensor - the block that is about to be
>entered. A1 and A2 will watch the next main and diverging blocks,
>respectively, while B and C will watch the mainline block in the
There are also two ideas here, and I (we) don't always use
Each sensor watches a piece of track. The prototype calls this a
track circuit (though these can overlap, and our sensors generally
don't); Digitrax calls this a detection section, and other
manufacturers have other names.
But those are not necessarily exactly the same as "the track from
this signal to the next signal" (sometimes called a block or a
I think Phil Klein was the one who wanted to have multiple detection
sections in a single block, because part of his layout is wired that
For another example, I know a modeler here who's very interested in
"automatic stopping of trains in front of red signals". He's got the
track between each pair of signals divided in a short detection
section at each end, and a long one in the middle. The short ones
let the computer (which is running a custom QBASIC program that's
just incredibly convoluted) know when the train is coming up on the
signal, so it stops in the right place.
>- What I really want to enable is setting a signal red if the next
>block is occupied, yellow if the next block is clear but the one
>following that is occupied, and green if there are at least two
>unoccupied blocks ahead. So I may decide that watching multiple
>sensors is desired, but that they are not treated the same (as with
>current SSL) - sensor 1 occupied results in a more restrictive signal
>than sensor 2 occupied.
>- However, my current thinking is to implement this 'lookahead' not by
>looking at the 2nd sensor, but by looking at a signal for the
>following block. This logic would be:
>- Current signal aspect is RED if the next block is occupied.
>- Current signal aspect is YELLOW if the next block is clear, and the
>next signal is RED
>- Current signal aspect is GREEN if the next block is clear, and the
>next signal is YELLOW or GREEN.
Right. That's what the current simple signal logic does, and it's
pretty much the definition of ABS signalling.
The next signal, instead of the next block, is used because there can
be _other_ reasons that the signal is set to "stop". The "approach"
aspect, one of who's appearances is "yellow", tells the engineer to
be prepared to stop at the next signal since it might still be red.
>For benefit of anyone that may not be familiar with CTC operation,
>I'll give a brief overview of the way I understand it. The
>description below is for a fully manual version of CTC - signals
>controlled purely by the dispatcher. Following this I'll talk about
>an integrated version of CTC that also uses the Mod-SSL logic above.
One can certainly have different functions on a model. Nick Kulp's
panel, for example, is meant to _look_ like a CTC panel, but actually
_work_ as just a regular old model railroad control panel, where you
flip toggles to change turnouts.
>- For each turnout on the layout, there are 3 controls at the CTC
>panel: a Turnout lever, which can be set either N(ormal) or R(everse)
>(or closed and thrown, if you prefer); a Switch lever, which can be
>set to clear either (E)astbound or (W)estbound traffic, or set to the
>center position to clear nothing; and a Code button. Moving the
>levers does not actually do anything; pressing the code button is what
>triggers action to be taken based on the current setting of each lever.
The code button sends the "codes" (toggle settings) as a request to
the vital circuits. They'll do it if and when they can, but not
before. (They're really stubborn that way!)
>- So to change the position of a turnout, I set the lever to the
>desired direction (N or R) and press the code button. Indicator lamps
>above the two switch positions light to show the actual position of
>the turnout. So if a turnout is set N, and I want to set it to R, I
>move the lever - but the light will still be on N, indicating that
>nothing has happened yet. I press the code button, the turnout is
>moved, and then the light over R will light indicating the new
That's an excellent first step. Let's get that coded, but let's try
to leave ways to make it more realistic by requiring signals, etc, to
be correct before it will move (there are already people who really
want that). I'll talk a little bit about that in a reply to a later
>The indicator light can also change to indicate that a
>turnout has been moved by someone other than the dispatcher.
On the prototype, there's a way to handle this that involves another
button on the CTC panel. Basically, the dispatcher and train crew
have to walk through an exchange of authority before the turnout can
be thrown in the field, and the light ends up blinking on the panel
to indicate that its under remote control. You can never have a
turnout under the control of _both_ because that's a good way to get
somebody's foot crushed, etc.
>- For signaling, a single lever affects the operation of all four
>signal heads around the turnout. If the lever is in the center
>position (and the code button is pressed to make this setting
>effective), then all 4 signal heads will show a red aspect. If the
>lever is in the E(astbound) position, then signal heads for trains
>traveling in that direction will be given a green indication. If the
>lever is in the W(estbound) position, then westbound trains will be
>given the green. (I'm not sure if this accurately describes prototype
>practice, so if anyone has better info please correct me).
Right, except with the caveat of "green only if safe; may therefore
be yellow or red"
>In the integrated version I'm thinking of, the center position would
>not cause red aspects to be shown all around, but instead would just
>fall back to the Mod-SSL logic.
I think this should be a matter of two different modes, or even
better two different configurations that one loads.
>Add 2 new PanelPro object Types
>1. Switch: any element that can take multiple appearances based on
>setting, and which executes code when changed
> There are 3 subtypes:
> 3-position switch: used for CTC Signal lever (E, center, W)
> 2-position switch: used for CTC Turnout levers (normal / reverse or
>closed / thrown)
> Momentary switch: used for code button
>Switch objects (perhaps another name would be better, since many use
>the word switch to signify a turnout) don't directly map to physical
>objects on the layout (unlike, for example, turnout objects). The
>only purpose of a switch is to invoke some bit of code; the code may
>control one or several layout objects as a result. For the 2 & 3
>position switches, each click cycles the switch to its next setting.
>For a momentary switch, the appearance can change to indicate the
>button has been pressed, but then immediately returns to normal
>appearance when released.
The new "Memory" NamedBeans might be just the right basis for
building these. It can have multiple states, and can be displayed,
There is a MemoryIcon class to display them, but it doesn't know
about the things that should be done when they are clicked
(momentary, etc). It would be easy to subclass that to get the right
behavior (I hope)
>The CTC Signal and Turnout levers would have no logic associated with
>them - all of the logic is embedded in the 'code' button, which will
>then query the state of each lever to determine what action to take.
I think perhaps a move MVC approach to this, with some underlying
controller that listens to the buttons, might end up being easier to
integrate. That's because I can imagine somebody not wanting a code
button ("Just have it go over automatically when I set the panel
levers!"), somebody else wanting fleeting (a way of deferring the
code button action), etc.
>New / Modified PanelPro dialogs:
>Modified SSL dialog: enter the following:
> Turnout being protected
> For each of 4 heads (A1, A2, B, C), enter:
> Sensor for next block
> Signals for following block (1 or 2)
> ? use yellow as most-pemissive on diverging route
There's a odd (due to historical reasons) thing about the existing
simple signal logic: It's organized by _signal_, not by block. So
it handles one _signal_, not the signals protecting one _block_ or
one CTC section (also called an OS section, Control Point, etc).
Maybe that should change, with another object introduced to represent
the _block_ and signals.
But generally the prototype railroad logic doesn't have a "block"
circuit, in that there's some logic that's common to all the signals
and controls them. The logic equations for each signal head are
written independently, so they can be checked independently.
>- I'm a little fuzzy on how flashing yellow is used in current signal
>logic (and for that matter, how it is used on prototypes) -- I can
>amend the above to include enabling flashing yellow in the appropriate
>circumstances, once I understand what they are.
"Flashing yellow" appearance on a single head is usually the aspect
called "approach medium", "advance approach", etc (name differs be
railroad and era). The indication is that there's an approach (e.g.
an appearance of a yellow on a single head) as the next signal. On
the SP, it was called "advance approach", and indicated:
Proceed prepared to stop at second signal. Freight trains
exceeding 45 MPH must reduce
speed by at least 10MPH before passing next signal unless the next
signal displays a
clear, approach diverging, or advance approach"
That's a more complicated way to say the same thing as "watch for an
approach at the next signal"
"Advance approach" was also represented by Flashing Yellow (FY) over
dark, FY over dark over dark, FY over red, FY over red over red, or
CP flashing yellow, depending on how many and what type heads the
Bob_Jacobsen@..., +1-510-486-7355, fax +1-510-643-8497, AIM JacobsenRG