Skip to main content

JMRI: Turnout Feedback

Model railroaders want different things when it comes to knowing the status of the turnouts on their layout. Some are quite happy to say "I told it to move, that's good enough for me". These people don't worry about whether a turnout on their layout actually moved when they told it to. Those people can just ignore this page, and leave the JMRI settings at their default.

But some modelers want to have better information about the status of the turnouts on their layout, and so use some form of "feedback" to indicate turnout position. This could be as complicated as two microswitches, adjusted to only close when the turnout is properly seated in either position. Or it could be something simpler.

In the code, Turnout objects actually know about two different states: "Commanded" state and "Known" state. The commanded state is "This is what was asked for last". The known state is "This is what's actually correct on the layout as far as I know".

Built into both LocoNet and XPressNet are limited abilities to monitor what is happening on their networks and adapt to messages about Turnout state changes. All the other protocols normally use a "you told it to change, so it did" logic. In other words, when something in the code (the Turnout Tool or a script) commands a state change from closed to thrown, the default is for both both the commanded state and the known state to change to "thrown".

But it is also possible to control this in more detail if you have wired your layout to allow it.

The whole question of turnout feedback is then "How do we configure the program to understand the known state properly, given my layout hardware?"

If you go to the "Turnout Table" tool, you'll find it has four columns associated with feedback:

"Feedback"
This is the "known state". You can't change it, but this column will show you what the program thinks it is.
"Mode"
This is the feedback method used by this turnout. (You can change it for each turnout individually, but note the change doesn't take effect until you click somewhere else, and you might need to add some sensor names in the next column(s))
"Sensor 1", "Sensor 2"
These define the sensors needed by certain types of feedback. You can type a sensor number, system name or user name here; the program will change it to the system name that it needs.

Available feedback modes are:

DIRECT
The default in many cases, and also the original behavior of the program. When something tells the turnout to change, it's just immediately assumed that it actually did it.
ONESENSOR
The turnout watches the sensor defined by the "Sensor 1" column, which is probably hooked to a microswitch on the turnout or similar. When the sensor is Active, the turnout is known to be in the "Thrown" position. When it's Inactive, the turnout is known to be in the "Closed" position.
TWOSENSOR
The turnout watches two sensors defined by the "Sensor 1" and "Sensor 2" columns, which are probably hooked to microswitches at either end of the turnout's throw bar. When Sensor 1 is active, the turnout is known to be thrown. When Sensor 2 is active, the turnout is known to be closed (normal).
MONITORING
Default for LocoNet turnouts (and probably XpressNet soon), this means the network is monitored for messages about the status of the turnout. This mode is only available for certain protocols, i.e. some protocols can't do the monitoring properly, and don't have this choice.
INDIRECT
Currently only available for LocoNet turnouts, this informs the program that the turnout is being driven by a Digitrax DS54 with a microswitch attached to the switch lead. For more information, see the DS54 page.
EXACT
Currently only available for LocoNet turnouts, this informs the program that the turnout is being driven by a Digitrax DS54 with two microswitches attached to the switch and aux leads. For more information, see the DS54 page.

Most people will (and probably should!!!) stick with the default feedback type that the software selects for them.

Operation

When feedback is used, Turnouts can start to behave in complicated ways.

Simplest Case

The most common case is JMRI commanding turnouts to move, and they move properly. The sequence is then:
  1. JMRI commands the Turnout to move by setting the commanded state to e.g. THROWN.
  2. The Turnout object figures out the right commands to send to the layout hardware, and works with the rest of the program to do that.
  3. The position changes on the layout.
If no feedback (really, DIRECT feedback) is in use, the known state of the turnout will also change in step 1. At that point, icons on panels, signal logic, etc will all be notified of the change and react.

Simple Layout Feedback

The simplest case for using feedback from a microswitch on the layout is similar:
  1. JMRI commands the Turnout to move by setting the commanded state to e.g. THROWN.
  2. The Turnout object figures out the right commands to send to the layout hardware, and works with the rest of the program to do that.
  3. The position changes on the layout.
  4. A microswitch detects that position change, and informs the layout electronics, which in turn changes an input to JMRI.
  5. That input is connected to a JMRI Sensor object, which changes its state e.g. from INACTIVE to ACTIVE.
  6. Because the Turnout is watching that Sensor for ONESENSOR feedback, when the change occurs it sets the known state of the turnout to THROWN.
This sequence takes a little time, but the known state of the Turnout isn't changed until the points have actually moved on the layout. Then, icons on panels, signal logic, etc will all be notified of the change in known state and react.

Uncommanded changes on the layout

Feedback allows JMRI to detect that something has changed due to action on the layout, instead of a command from the program. For example, if you're using feedback from a turnout, you might see something like this sequence:
  1. The program sets the commanded state to THROWN, and instructions go out to the turnout telling it to move to that position.
  2. Later, the feedback information comes back to indicate that the movement has taken place. This sets the known state in JMRI to THROWN.
  3. Later, and independently, you move the turnout on the layout to the CLOSED position, perhaps with a ground throw or local pushbutton.
  4. This causes the feedback information send to JMRI to change.
  5. Because of this, the known state is changed to CLOSED.
  6. At this point, JMRI makes the assumption that you wanted this to happen; in effect, a command was given on the layout (not in the program) to move the turnout. So JMRI changes the commanded state to CLOSED also. Note that this last transition in commanded state does not send commands to the layout; it's just a change within in the program.

    TWOSENSOR feedback and inconsistent state

    Bus-based systems and input messages