Block control and automatic running

What is a block and why use block control?

A block is a defined section of the layout that only one train may occupy at any given moment. As soon as a train enters a block, that block is closed to all other trains until the train leaves it again and the block is released. This principle — borrowed from the full-size railway world — is the foundation of virtually every automatic running system: without block control, two trains could run towards each other or overtake each other on the same stretch of track without the software noticing.

Block control therefore comes down to two things that need to work together: knowing whether a block is occupied (occupancy detection), and deciding which train may go where based on that (route management). Both are covered below, with the caveat that exactly how ModelRailPro implements this internally has, in places, not yet been verified on a real layout.

Occupancy detection: how does the software know a block is occupied?

Occupancy detection (also called feedback, see the feedback and occupancy detection guide for the communication side via s88, LocoNet, CAN or RailCom) is the mechanism that translates the physical presence of a train into a signal the control software can read. Three common, brand-neutral methods exist:

• Current sensing: the block is electrically isolated from the rest of the layout (via an isolated rail section), and a current-sensing module or resistor bridge measures whether current flows through the section. As long as the train — or even just a lit carriage or resistor axle — is present in the section, the "occupied" signal stays active. This is the only one of the three methods that intrinsically gives a continuous status for the whole section, for as long as the train is there.
• Reed/hall sensors: a magnet under the train triggers a sensor at a fixed point in the track. This is a point trigger: the sensor reports that a train passed at that moment, but does not provide a continuous "occupied" status for the rest of the section.
• Optical detection (infrared light barrier): an IR transmitter/receiver detects interruption of the beam by a passing train. This too is fundamentally a point detector, just like reed/hall.

For block control where the software needs to know "is this whole block clear or not", current sensing is functionally the most suitable, since reed and optical sensors only register a moment of passage and therefore need to be combined with logic that derives a whole-section occupied/clear status from that (for example: occupied from sensor A until sensor B has been passed).

Routes and collision prevention

Once the software knows which blocks are occupied, it can reserve and release routes (paths spanning multiple blocks). The basic principle behind this kind of interlocking logic typically follows this cycle:

1. Reserve: before a train starts a route, the system checks that all blocks on that route are clear, and reserves them exclusively for that train.
2. Run: the train enters the reserved blocks one by one; each block shows "occupied" as soon as the train enters it.
3. Arrival: the train reaches the next block or a signal/stop marker, where the route ends or waits for the next release.
4. Wait/release: once the train has fully left a block, that block is released for other trains again.
5. Next route: the cycle repeats for the next train, or the next leg of the same train.

The key point of this cycle is that blocks on a route are reserved in advance, not only once the train has already arrived. This is what prevents two trains from claiming the same stretch of track at the same time.

Fail-safe: what happens if occupancy detection falters?

A fundamental safety principle from the world of interlocking — independent of any specific DCC standard — is that a system should fail safe on doubtful, missing or conflicting feedback: not releasing the next block, or stopping the train, rather than proceeding on the assumption that everything is fine. In other words: when in doubt, stopping is the safe choice, not continuing.

This is a general design principle, not an NMRA DCC standard. Exactly how ModelRailPro handles this internally — what behaviour the software shows when an expected occupancy signal is missing, arrives late, or conflicts with another sensor — is an application-level design choice. to be confirmed on a layout

Braking and stop sections

Besides occupancy detection, there is often a need for a short section just before a signal or block boundary where an approaching train starts braking early, so it does not overshoot the boundary and enter the next block while that block is still occupied or not yet reserved. One well-known technique for this uses an asymmetric DCC signal (often referred to under a brand-specific name such as "ABC" braking): the decoder recognises this asymmetry in the track signal and brakes on its own, without a separate command being needed.

Important to know: this is not a universal NMRA standard, but a manufacturer-specific extension. Whether and how a decoder responds to it varies by manufacturer and is usually set via a CV that can differ between manufacturers. Whether and how ModelRailPro drives this kind of asymmetric braking cannot be derived from documentation and does not appear to be a current feature of the app — so it should not be treated as a confirmed feature. to be confirmed on a layout

Automatic running and learn mode

A commonly used concept in control software in general is a "learn mode": while running trains manually, the software records which blocks and routes exist, how long a leg takes, and where signals or stop markers are located. That information is then used to plan and run automatically later, without every route having to be programmed separately.

The exact behaviour of learn mode in ModelRailPro — precisely what is recorded, how robust it is to varying driving styles, and how reliable the result is in practice — is an application-level design choice that cannot be derived from documentation. This should be confirmed within the app itself. to be confirmed on a layout

What do you need at minimum for reliable automatic running?

Regardless of which software you use, a few preconditions apply for reliable block control:

• Unambiguous occupancy detection per block: no false "clear" readings caused by dirty wheels, poor contact, or too light a load on a current-sensing module.
• Correctly defined, non-overlapping block boundaries that line up with the layout's actual rail isolation — a block boundary defined in software that doesn't match a real insulating gap won't work.
• Sufficient braking distance between the detection point and the actual block boundary or signal, so a train can come to a stop in time.
• Consistent, non-conflicting route reservation, so two trains never claim the same block at the same time.

Without this foundation, any automatic running system — regardless of the brand of control software — risks false stops or, worse, collisions.

Related guides