Concept
A turntable, transfer table or movable bridge is the one piece of track that can be pointing somewhere else while the rails on either side look perfectly normal. Routing a train onto a bridge that is not aligned to the stall you think it is drops it in the pit. So RailCommand treats a movable device as a gate rather than a piece of track: a route across one is permitted only when the product can positively vouch that the device is aligned to a position on that route, and that the train fits it.
The important consequence is that the gate fails closed. If it cannot account for the device's position it refuses the route rather than assuming. A refusal is the system working, not a fault — every refusal names a reason, and each reason has a specific remedy below.
Alignment is confirmed through the product. A bridge turned by hand, or turned before the app was started, is not something any running process can vouch for, and the gate says so.
How To
- Open the operating console for the session. A Turntables panel lists every turntable and transfer table on the layout; it does not appear on a layout that has none.
- Pick the track you want from the device's list and press Align. The list names the tracks as your crew does ("Track 4"), not by decoder number.
- Wait for the alignment to show as confirmed — the gate acts on the confirmation, not on the request. What "confirmed" requires depends on the device's confirmation mode (below).
- Set your route across the device as normal. With the device confirmed on an on-route position and the train fitting it, the route is permitted.
- To use a different stall, align again. A crew attestation naming a stall other than the confirmed one is refused and raises a dispatcher alert — see Safety Notes.
If a track is listed but Align is greyed out, that position has no number on the physical decoder. Re-run Assign for the device in the layout editor. The product will not command a stall the decoder cannot name, because the move would land somewhere nobody chose.
How an automatic move proves it arrived
Each device carries a confirmation mode, set by the layout owner in the turntable's editor dialog:
- Feedback — a wired position contact proves the bridge landed. The safest option; the default whenever position feedback is wired.
- Attestation — a person confirms each automatic move. The default when no feedback is wired. Pending confirmations appear on the Engineer Cab and, where the layout enabled that role, the Switchman screen, as an Alignment confirmations board. Press Confirm aligned once you have seen the bridge is lined. Until someone does, the route stays held — the device is waiting on you, not broken.
- Calibrated timing — no confirmation at all; the move is trusted on the calibrated swing rate. This is the owner's deliberate opt-out and the turn and step times must be accurate. Nothing proves the bridge landed, and after an emergency stop the position cannot be re-established from timing alone: the device must be re-aligned.
Leaving the mode unset means "the safest the hardware supports" — Feedback if a contact is wired, otherwise Attestation. The system will never choose calibrated timing for you.
An imported turntable that is not configured yet
A turntable imported from TrainController arrives without its position ring, because RailCommand does not decode that part of the file yet. Since 2026-08-14 the layout graph no longer treats such a device as a hole in the railroad: RailCommand models its legs from the track you drew — the stall tracks running up to the glyph — so bridge-to-stall routes appear in the derived route set, and the imported routes that cross the device stop reporting as unverifiable.
Those routes are not permission to run over it. They carry no bridge position, because none was decoded, so the route gate has nothing to vouch for and refuses the movement exactly as it does for any device it cannot account for. Set Route across an unconfigured device is still declined until you author its track plan in the turntable editor. Nothing about the gate changed; only the graph did.
This applies to imported devices and to no other case. A turntable you placed by hand and never configured derives no legs and no routes, and one whose authored track plan does not validate likewise derives none, with a warning naming the validation errors — you configured that device, so the error is the answer rather than a guess from the drawing.
If an existing layout's stall routes are still missing, the layout needs to be imported again: re-deriving cannot recover the stall count, which is read from the file at import. Derivation says so in a warning, and reports any shortfall against a decoded stall count rather than filling it.
The standing rule: re-align after every restart
After any restart of the desktop app or of the layout host, re-align every movable device before running trains over it. The system will not prompt you.
The record that attributes an alignment to a live, running process is held in memory. A restart empties it. Quit, relaunch, and resume a session and yesterday's confirmed alignments replay from the event store fully stamped, so the route gate permits them — while nothing running can actually vouch for where the bridge is pointing.
Treat this as an operating rule, like checking a switch before you line it. It applies after a planned restart, a crash, a host reboot, and after any software update.
Troubleshooting
"Turntable not aligned" (turntable_alignment_unattributable) — nothing in the running process has
confirmed where this device is pointing. Causes: never aligned since the app started, turned by hand, or a
confirmation that answered a superseded align. Align it and retry. This is the most common refusal and it
is not a fault.
After a restart you may get NO refusal at all — and that is the dangerous case. The two restart paths behave differently, which is the whole reason the re-align rule exists:
| After a restart you… | What happens | Your cue |
|---|---|---|
| start a fresh session | the device is unattributable and routes are refused | the refusal itself tells you to align |
| resume the previous session | alignments replay from the event store fully stamped, and routes are permitted | none — there is no diagnostic |
In the resume case nothing is wrong on screen and nothing is logged, yet no running process can vouch for where the bridge is physically pointing. That is why re-aligning after a restart is an operating rule you follow rather than a prompt you wait for.
"Alignment configuration changed" (turntable_alignment_stale_config) — this device's configuration was
edited after it was aligned, so the earlier confirmation no longer describes the same device. Align again.
"No single position serves this route" (movable_device_span_unsatisfiable) — the route crosses the same
device in two places and no one position serves both. Split it into two routes and run them in sequence;
no amount of re-aligning will fix it.
"Bridge exit not mapped" (movable_device_exit_unmapped) — a bridge exit has no track pairing bound to it,
so the product cannot tell where that stall leads. Author the pairing in the layout editor, then re-derive
the layout.
A route across an imported turntable exists on the Routes page but Set Route is refused — expected for a device whose track plan is not authored yet. The route is there because RailCommand modeled the device's legs from the drawn stall tracks; it carries no bridge position, so nothing can vouch for where the bridge is pointing and the gate declines. Author the device's track plan, re-derive, then set the route.
"Route hop unproven" (run_route_hop_unproven) — two hops on the route have no live connecting track.
Run a layout derivation and retry.
A route is refused right after I aligned it — clicking Align repeatedly on a moving bridge, or two operators aligning the same device at once, can leave the in-flight alignment unattributable. Align once more and let it settle. The gate is refusing rather than guessing, which is the intended behaviour.
Alignment seems fine but a crew attestation is rejected — see Safety Notes; a stall mismatch is refused by design.
Safety Notes
- A refusal is never a wrong permit. Every failure mode above declines the movement. If you believe a refusal is wrong, re-align rather than working around it.
- A crew attestation naming a different stall than the confirmed alignment is refused and raises a Critical dispatcher alert. Recovery is a fresh alignment. This exists because the two disagreeing is exactly the condition that puts a locomotive in the pit.
- Re-align after every restart (above). This is the one case where the gate can permit an alignment no running process can vouch for, so the operating rule covers it until it is closed in software.
- Automatic detection of a bridge contradicting its commanded position requires layout sensor wiring that is not yet present. Until it is, the product cannot catch a bridge that moves on its own — which is another reason the re-align rule matters.