RailCommand Blocks (Detection Blocks)

Concept

A RailCommand detection block is a named run of track that the layout watches for occupancy. On the schematic a block is a single straight segment of cells: exactly 1 cell on its thin axis and at least 2 cells on its long axis, horizontal or vertical — never diagonal. Editors clamp every create and resize to this rule, so a square or 1×1 input resolves to a horizontal 2×1; import keeps a decoded sub-minimum span as-is and warns.

A block's Track Class says what kind of railroad it is: Main, Branch, Siding, Yard, Lead, Industry, Staging, Interchange, Runaround or Maintenance. A block that has not been given one reads Unclassified, which is a state with a name rather than an empty field, and it is what you will see in the Block Editor list and in the class picker. RailCommand is block centric (owner ruling 2026-09-26): the block is the only thing that carries a Track Class. Track a block covers reads the block's class; track outside every block is a connector between blocks and has no class; a turnout, crossing or slip has none either, and each of its legs reads the class of the block it leads to. The cell properties panel on either editor shows a cell's class read only and says where it comes from. A block's division and aspect-paradigm override are the block's too. Marking a block Dark territory (no detection by design) says there is no detector; it says nothing about what kind of railroad it is, so a dark territory block still needs a class.

Dark blocks for track with no block (ADR-0271). A stretch of track, or segment, is the track between two turnouts, crossings, slips, turntables, transfer tables or end bumpers; a signal does not end one. When a TrainController import or a Save in the layout editor leaves a segment with no block, the system plans a dark block for it: dark territory, no sensor, no address, no signal and no class, named B row:column after the segment's first cell (the cell furthest left, then highest; the name counts rows and columns from 0 at the top left, so B 3:12 is the cell shown as 04/13), with a letter added when that name is taken (B 3:12b). Every position the pages show or ask for reads as TrainController shows it: row/column, counting from 1 and zero-padded to two digits (23/02 is row 23, column 2; row 125 reads 125/02). Only a dead end gets its dark block automatically: a stub or spur that ends at a bumper, or where the track simply stops, on one side and joins a turnout, crossing, slip, turntable, transfer table or connector on the other. Every other stretch with no block, such as track between two turnouts, a loop, or a piece joined to no turnout at all, is only suggested, because TrainController panels often needed track drawn between switches where no real track exists. A block is a straight run, so on a curving segment the dark block covers the segment's longest straight part, and on a segment with no straight part of two cells it is a single cell. The import review lists every dark block on the Blocks tab with an Include box, dead ends checked and suggestions unchecked, each with its panel, row/column, the track's cell count and why ("dead end (bumper at 06/10)", "between turnout at 06/04 and turnout at 06/10"); check a suggestion to add it, rename any of them, and tick Confirm dark. The completion summary lists the blocks added and the stretches left as suggestions. The editor's Save adds the dead-end blocks, says in one line what it added and how many suggestions there are, and lists the suggestions above the diagram, each with an Add button; Hide puts the list away until the number changes. After that a dark block is an ordinary block: attach detection to it, classify it, rename it, split it or delete it. Deleting one on a dead end leaves the track with no block, so the next Save adds one again; draw your own block on that track first. The import never changes a block it read from the file, and it reports any imported block drawn across a turnout or crossing instead of redrawing it. One exception needs no block and is never suggested: a piece of track only 1 or 2 cells long between two turnouts, crossings or slips is part of those turnouts' interlocking.

Block ends. A block's two ends are named by where they leave the drawing: Left end and Right end on a horizontal block, Upper end and Lower end on a vertical one, and, where both ends leave the same way, by the track each end meets (Toward Siding 2). The foul lengths, end signals, sensor positions and marker directions in the block settings, and the facing in Place Train, all use these names. For a block drawn on several switchboards, the first switchboard in panel order decides which end is which. If you redraw track so that a block's ends change places, the next Save moves each end's foul length, signal and sensor positions, any stop marker measured from that end, and any train placed in the block, with its end, so nothing turns around.

Block end caps. Inside each end of a block's box, a small dot with a short stem pointing outward shows whether a train may leave the block by that end, the way TrainController's block signals do. It is red for stop, amber for approach and green for clear, and grey when no dispatcher and no automation holds the block. While a session runs, an end nobody has reported on is the grey dot in a dashed ring. A cap is drawn only at an end a train may leave by, so a block whose Direction is Left Only or Right Only shows one cap. While you edit, every exit shows grey, because nothing is running. Hover over a block to read its ends in words, for example Right end: Clear. On the web today a block that is reserved or locked has an end indication nobody calculates yet, so its caps show the dashed ring; an exit lock shows red. Changed 2026-09-25, on both schematics and in the Block Detail panel.

An exit signal of its own at every end (owner rulings 2026-09-26 and 2026-09-29). Every block whose two ends the drawing orders has its own exit signal at each end, two in all, bumper ends included: the signal a train leaving the block by that end passes. TrainController has no entrance signals, so neither does RailCommand. The block's own signals follow RailCommand's internal rules. A signal you drew yourself is never taken over: it keeps its imported logic or the rule set you chose, and the block's own exit signal stands beside it. Where the block's own signal has no hardware it is a virtual signal, placed on the block's last cell at that end and drawn as a small hollow dashed ring beside the track, so rules, routes, the CTC board and automation always have a signal at every block end. They are named for their block and end, for example Siding 2 left end exit, and they move with their end when you redraw the block. A block that branches, or has only one end, gets none until its drawing gives it two ends. Each person can hide virtual signals with Show virtual signals in the Layout Editor's display options.

Locking a block end. As in TrainController, each end's entry and exit can be locked on the desktop, from the block's right-click menu on the operating diagram or the CTC board. A locked entry keeps at Stop the exit signal of every block whose route runs over that entrance, until the lock is released, and refuses any route, dispatch or automation into the block at that end; a locked exit holds that end's exit signal at Stop and refuses trains leaving by that end, and its end cap shows red. A small padlock marks each locked end, beside the track on the side of that end's exit signal, and the board lists every lock with a Release button. The lock shows who set it, why and when, stays through restarts and sessions until someone releases it, and rules can test, set and release it. Where two signals stand together at an end, a click picks the signal whose symbol it lands on, and a click beside them picks the block. Whole-block track-work protection is separate and unchanged.

Markers in the block editors. A block's stop, brake and speed markers point the way they apply. A marker for trains moving right sits below the block and points right; one for trains moving left sits above it and points left. On a vertical block the right side reads bottom to top and the left side top to bottom: markers for trains moving up sit on the right and markers for trains moving down on the left. A stop marker is a red triangle, a brake marker an amber tag carrying its ramp (in inches), a speed marker the same tag carrying its limit, and entry and exit markers a white bar. A marker measured from one of the block's ends applies to trains entering at that end, and so does a marker imported from TrainController whose block's ends are ordered. A marker whose direction nobody knows yet is drawn both ways with a dashed outline. Markers show only in the block editors: the Block Detail panel, the Layout Editor's block settings and the desktop's Block settings and stop marker strips. No board draws them, while you edit the layout or while it runs; the board shows each block's end caps (changed 2026-10-06, the owner's ruling). The block editors draw a block's markers and sensors, and every surface its end caps, at the same places and pointing the same way, also on a block whose ends the layout orders from its lower or right end (changed 2026-10-06).

On the CTC dispatch board. A dispatcher's CTC board in dispatch mode is drawn as a line schematic, like the RailCommand Dispatching panel on the public site. Each track is one line, and a block is its name set beside its own track, with no box, no end caps and no markers; the board's signals show its ends. Every block the board draws is named: a generated board names a branch block (a spur or a siding off a turnout) on the row beside its track, as it names a siding, and a long name of two words is set on two lines rather than shrunk. A block's state is the colour of its track: red while a train occupies it, green while a route is lined through it, purple under Track and Time, blue while it is out of service, dashed grey while its detector has not reported, and slate when it is clear. Connector track outside any block keeps the slate line. The Blocks table and the Mileposts page list each block once, from the layout's track plan: a CTC board that draws the same blocks adds no rows. Changed 2026-09-27. The RailCommand desktop's CTC board draws the same line schematic, from the same shared track editor, with each block's track coloured by its live state.

Train tags. In Simulate and Live, and on the CTC dispatch board, a train standing in a block is shown by a train tag: a navy plate with the train's name in cream, drawn over its head block. The tag's words never read upside down: a horizontal block reads left to right, a vertical one reads top to bottom, and a diagonal turns 45 degrees. A tag shows three things when they are known and nothing when they are not; hover over it to read the same facts in words:

• Direction of travel. An arrow at the leading end of the tag points the way the train is moving on the screen. A stopped train has no arrow.
• Forward or reverse. The arrow is solid when the train moves forward, its own front leading, and hollow with a small R when it moves in reverse, as in a shove or a backing move.
• Engine end. A small locomotive sits at the end of the tag the engine is at. A train with engines at both ends (push-pull, or a helper on the rear) has one at each end. When the engine's place is not known there is no locomotive, and the tooltip says Engine position unknown.

A train you placed with Place Train stands facing the end you chose, so it has no arrow and its tooltip says which way it faces. A live train's tag takes its arrow and locomotive marks from the desktop that hosts the session, when that desktop reports them; until it does, a live tag has no arrow and its tooltip says Direction unknown, rather than guessing. When a train stands in exactly one block behind its head block, that block gets a muted tail tag; when it spans more, which block is its rear is not known and there is no tail tag. The tag stays inside its block: a long name is drawn smaller, down to 11 points, and is then cut short with an ellipsis (the tooltip gives the whole name). The tag's border takes the block's colour (salmon when occupied, amber when reserved), so the two outlines read as one. A block a tagged train stands in keeps its own name as its label; the tag names the train. Clicking or double-clicking a tag does what clicking the block does. The desktop draws the same tags from the same geometry.

Paint mode is how a classification is given to many blocks at once. Both editors have it, with the same brushes: one per Track Class, a Dark territory toggle, and an Unclassified eraser. Pick a brush, then click a block or drag across several, and each block you cross takes that brush once. The keyboard does the same: with a brush in hand, Enter paints the block under the cursor, . and , step through the brushes and Escape puts the brush down. Painting acts on BLOCKS, never on raw cells: a stroke that crosses track outside every block passes over it and says nothing, because that track is a connector between blocks and carries no class of its own. A drag writes one block at a time on either editor, so a block the write could not reach leaves the rest of the stroke saved: the report names that block, says no verdict was reached for it, and the blocks painted around it stay painted. The eraser clears the block's classification, so the block and the track it covers read Unclassified; a class brush leaves the Dark territory flag alone, and the Dark territory brush leaves the classification alone. A Dark territory DRAG is one gesture with one intent on either editor: it takes its direction from the first block it crosses and writes that same state to every block after it, and the report says which way it went. On the Avalonia desktop a block whose write is refused shows the refusal at the block itself, in the engine's or the host's own words, outlined in red; a place with nothing to paint, such as a piece of track belonging to no block, is outlined in amber instead, because one is something to go and fix and the other is something you can act on where you are. Switching the desktop canvas out of Edit puts the brush down, the way it puts the element palette down.

Clearing a block's Track Class does the same thing wherever you do it. Choosing Unclassified in the block's settings modal or on the Block Editor page clears the block's classification exactly as the eraser brush does, and the track the block covers reads Unclassified with it. Editing anything else about a block leaves its classification alone. A cell's class is not edited on the cell: the cell properties panel shows it read only, and a class sent for anything but a block is refused with a sentence naming the block to classify instead.

An unclassified block is drawn distinctly on both schematics while you are editing: its box is stroked in a dashed amber outline. It is an outline rather than a fill because a block can be unclassified and dark territory at once, and the dark neutral fill has to keep reading; a block in both states shows both. Operating displays are unchanged, on either editor: the outline is drawn in Edit and in no other display mode, because classification is something you author rather than something you operate. On the desktop the outline appears on a layout you are editing online; while a layout package is mounted the package does not yet carry the block-level answer, so the desktop draws no marking at all rather than guessing (see the troubleshooting list).

CTC generation is refused until every block on the chosen switchboards is classified. RailCommand is block centric: blocks carry the designations, and track outside every block is only a connector between blocks, with no class of its own, so it never stops generation. A dispatcher panel cannot tell a mainline from a yard ladder until each block says which it is, and the refusal lists each block by name so you can go straight to it.

Each block carries a governed config: zero or more sensors that report occupancy, and markers that tell an approaching train where to brake or stop. A current sensor detects a length (drawn as a bar); a point sensor is a momentary IR/reed contact (a dot). Occupancy is the logical OR of the block's sensors: any active sensor recolours the whole block bar. A marker's type names it: a Stop marker is a precise stopping point, a Brake marker carries a ramp (the braking distance before its point), and a Speed marker is where a train changes speed. It serves layout owners and editors configuring RailCommand, and operators reading block state in a session.

When a layout is imported from TrainController, every block the file saves arrives, whatever its speeds: a speed saved as a formula is kept with the block as written, and that block, like one saved with no speed, has no speed limit of its own. When a layout is imported from TrainController, every block's markers arrive with the block, exactly as the file saved them: the type (Stop, Brake or Speed), the distance from the sensor it is measured from, the ramp, the alignment on the train and Scheduled Stop Only, with no value rounded (TrainController's 50.8 cm is 508 mm). Where the block's ends are ordered, each marker also records the end trains enter at for it to apply. A marker measured from one of the block's own sensors (the sensors TrainController keeps in the block, with no contact drawn for them) names that sensor: each such sensor has its own identity, is bound to its input as a sensor of its own beside the block's detector binding, and keeps that identity if you place it on a cell of its own. Every marker is assigned to a sensor of its block, so a marker measured from one of the block's flagmen names that flagman, and one measured from a contact TrainController saved with no connection names that contact, which stays one of the block's sensors with no address (bind it like any unwired sensor). A marker the file saves with type 0 is an Action marker: it keeps the operations it runs when a train reaches it, exactly as the file saved them, and they wait, held back with their reason on the layout's Automation rules page, until the RailCommand desktop runs action markers; it never stops or brakes a train. A marker whose type the file does not name is kept as a plain Marker marked type not read. The import result counts the action markers and each marker that needs a look in the Block Detail panel, and names each block whose markers have no known direction, with why (for example, a turntable bridge's ends are not found on the drawing); what the import could not read about a marker is listed on its Warnings tab. When the import cannot read a block's members from the whole file (a file from an earlier TrainController version), it reads them from the block's own record and its notes say those members are not verified. The import's Warnings tab also counts the marker records it saw rather than reporting them as skipped contacts: a marker is a block-family virtual contact, not a wired sensor, and it never carries a feedback address.

The operating engine enforces these markers for automated trains. A train arriving in its destination block no longer brakes at the block boundary: it holds speed until the brake point (a Brake marker's distance, or as late as its calibrated stopping distance allows before a Stop point), then decelerates to stop at the marker. A destination block with no markers keeps the original behaviour (braking begins the moment the block reports occupied), and any unresolvable configuration falls back to that same immediate braking, the safe direction. Markers imported from TrainController are kept and shown, and each applies to trains entering at one end. The desktop runs an imported stop or brake marker that is measured from the train's head and whose end the import is sure of, for trains entering at that end, once a stop placement is saved for that end of the block. Any other imported marker (a speed marker, one measured from the train's middle or tail, one with a formula, or one whose end the import could not tell) is shown with the reason it does not run.

Blocks carry the track metadata (ADR-0271 rule 4). A block's length, measured length, speed limits, grade, elevation and stop markers are all set on the block; a piece of track carries none of its own. The track graph RailCommand operates from takes each stretch of track's length, speed limit and grade from the blocks it runs through: a block's length is shared among the stretches over it, a stretch takes the lowest limit of its blocks, and its grade follows the block's direction. Track outside every block (the short pieces between two turnouts, and the run from a block's end to a turnout) belongs to the turnouts and carries nothing, and the turnout keeps its own speed limits. A length measured at the layout by RailCommand is sent to the website at once, even during an operating session, because a measurement is a fact rather than an edit to the drawing; it reaches the operating package on the next download. A stop or brake marker belongs to its block and is measured either from one of the block's own sensors or from one of the block's ends. RailCommand can send a stop measured from where a train enters the block; that stop is kept on the block, applies to trains entering at that end, and stays confirmed when the layout is downloaded again. The Block Detail panel names the end such a marker is measured from ("measured from the left end", using the names described under Block ends). A block whose ends cannot be told apart (one drawn across a turnout, say) accepts only stops measured from its sensors.

Track speed (RailCommand #286, 2026-10-04). Every block runs at its track speed: the lower of the rule set's speed for the block's track class and the block's own limit. A block with no limit of its own runs at its class's speed, and a limit of 0 is no limit. The rule set's speeds are Main 60 mph, Branch 40, Staging 30, Siding and Interchange 25, Runaround 20, Lead 15, Yard and Maintenance 10, and Industry 5. A block with no track class runs at Main's 60. A block's own limit can lower its track speed but never raise it above its class's speed: a Siding with its own 40 mph limit still runs at 25. The Block Editor's Track Speed column shows the speed each block runs at, and the expanded row says where it comes from, for example "Track speed: 25 mph (Siding, from the rule set)" or "Track speed: 40 mph (this block's own limit)". RailCommand on the desktop works the track speed out with the same rules and the same table, so the two always agree. The website shows the track speed and RailCommand enforces it on the layout. A train also never runs faster than its slowest vehicle's own top speed (RailCommand #286): every vehicle, cars included, can carry one, set as Top speed (scale mph) on its asset's add or edit page, and RailCommand holds the whole train to the lowest of its track speed and those top speeds, naming the vehicle when it is the one that governs ("limited to 25 mph by GP9 101's top speed"). That limit is the layout's rule set's row CIVIL-VEHICLE-1, so it can be amended or turned off like any other rule. A vehicle imported from TrainController has no top speed until one is set here.

Holding a block occupied after its detector clears. A current detector sees a train only where there is current draw. Cars without resistor wheelsets draw none, so as soon as the locomotive leaves a block its detector goes dark and the block reads clear with the cars still standing in it. The occupancy hold fixes that: when a block that was occupied reads clear, RailCommand keeps it occupied, with the same train, for a set number of seconds, or until the train is seen in a block it was not in when the detector cleared, whichever comes first. If the detector reports occupied again, the countdown is cancelled. While a block is held its signals stay at stop, the route through it is not released, and automation reads it as occupied, exactly as if the detector still saw the train. A block that was never known to be occupied, a block an operator clears by hand, and a dark territory block are never held. The hold is set in seconds, from 0 to 600, and fractions are allowed. The layout has a default, and each block can set its own value or use the layout default. A block's own value always wins, and 0 is a value: it turns the hold off for that block even when the layout sets one. With neither set, nothing is held, which is how RailCommand behaved before the setting existed. A TrainController import leaves the hold unset, because no TrainController setting carries it. It is a different setting from Min Hold Time on the Speed & Rules tab, which is how long a train waits in the block before it departs. In RailCommand, Why isn't my train moving? and Layout feedback say when a block is being held and for how many more seconds.

Maximum train length. A block can say how long a train it takes, which can be longer than the block itself: a siding drawn 39 inches long may hold a 112-inch train. It is a different setting from the block's length. A block imported from TrainController takes the maximum TrainController saves for it (its Train Length / Maximum), in centimetres exactly as saved; a block TrainController saved with no maximum imports with none, and the value the file saved is kept with the block either way. The maximum is shown and typed in the block's own length unit and stored in centimetres, decimals and all. Leave it empty for no maximum; 0 or less is refused with the reason. It reaches RailCommand the next time the layout is downloaded.

Switches own their own data (ADR-0271 rule 3, 2026-09-26 amendment). A turnout, crossover, crossing or slip is not part of any block, and it keeps three things of its own. Its restrictions, set on the General tab of the Layout Editor's turnout dialog or in the desktop editor's switch properties: a speed limit for each route through it (the normal and the diverging route, or for a three-way the straight route, the left leg and the right leg; an empty box is no limit), and Trailing-point moves only, for a switch trains may pass only from a leg toward the points, such as a spring switch or one without a facing-point lock, over which RailCommand will not plan a facing-point move. Its FRA track class, chosen on the same tab (Class 1 to 5), or Not recorded. The speed a class allows depends on the train: the layout's operating rules hold one limit per class for freight trains and one for passenger trains (seeded from 49 CFR 213.9: freight 10, 25, 40, 60 and 80 mph, passenger 15, 30, 60, 80 and 90 mph for classes 1 to 5), and you change them there. RailCommand treats a train carrying passenger cars and no freight cars as passenger, one carrying freight cars and no passenger cars as freight, and any other train by the lower of the two; a block with a recorded FRA class uses the same limits. A train crossing the switch is held to the lowest of the switch's route limit, its FRA limit for that train and the limits of the blocks around it. And its throw count, which RailCommand on the desktop keeps for maintenance (see the switch maintenance page in the signals and object tables article). A switch's restrictions and class reach RailCommand the next time the layout is downloaded.

Mileposts. A block holds three mileposts: one at each end and one at its center. Each end is named by where it points on the diagram (Left end, Upper end), the same names as everywhere else in the panel, never A or B. A milepost is a number of miles to two decimal places, from 0 to 99999.99, with an optional prefix of up to three letters for railroads that letter their mileposts by line (the B in MP B123.4). You can type it as 123.4, B123.40 or MP 123.4; it is stored and shown as B123.40. Anything else, a third decimal place, a sign, a fourth letter, is refused where you typed it, and nothing is saved in its place. When both ends have a milepost on the same line, the center offers Use midpoint, halfway between them; it is stored only when you press it or type your own value. Mileposts you type are treated as approximate, because they are usually read off the fascia: RailCommand never refuses one for disagreeing with the others, it shows a warning beside it instead. The warnings are a center that is not between its two ends, and, when the layout numbers its mileposts by distance, ends that run the wrong way for the direction mileposts increase toward, and ends much further apart or much closer than the block's length makes them. A milepost reaches RailCommand the next time the layout is downloaded, at the block's own record in the layout the desktop reads; a block without one downloads exactly as it did before mileposts existed. Signals, turnouts, control points and operations locations hold one milepost each, with the same rule (see the signals and routes articles).

Milepost scheme. Layout Settings says how the layout numbers its mileposts. No scheme is the default. By distance along the track sets how much layout is one milepost mile (the Wagner Lines uses 2 feet, which is 609.6 mm; enter it in feet, inches or mm), the starting milepost, and the direction on the diagram mileposts increase toward; when the layout has a railroad direction, each choice also says which one it is (Right on the diagram, Railroad East). Entered by hand means you type mileposts where they are marked. Whichever you choose, a milepost you type always wins: values worked out from the scheme are a later step, and they will be kept apart from the ones you type, never written over them.

The Mileposts page (/app/railcommand/layouts/{LayoutId}/mileposts, linked from the layout page's Layout Objects tab and from Layout Settings) is for typing a whole layout's mileposts quickly. Every block is one row: its name, then the end the track order enters by, the center, and the end it leaves by, each end named by screen direction. Tabs hold Control points, Signals, Turnouts and Locations. Sort by Track order, Milepost or Name (and Subdivision on the Locations tab), and filter by name. Track order walks the layout's track from a starting block you choose (by default a block at the end of the track, walked in the direction mileposts increase toward, or toward Railroad East, North or Up when no scheme sets one): it lists blocks in the order a train meets them, follows the straight route through each turnout first, lists each diverging branch right after the line it leaves with the turnout it leaves from, lists every block once however the track loops, and puts track it cannot reach at the end, a piece at a time. Signals, turnouts and control points sort by where they stand in that walk. Press Enter to move down the column, so you can read the fascia and type. Nothing is saved until Save, which saves every change at once or, if any box holds something that is not a milepost, none of them, and marks the ones to fix. The page remembers your sort, tab and starting block for that layout in your browser.

How To

Prerequisites: an imported or authored layout, and owner/editor access in the organization that owns it.

Review and configure blocks on the Block Editor page:

1. Open /app/railcommand/layouts/{LayoutId}/blocks. Summary cards count Total Blocks, Well Configured, Missing Detection, No Signal, and Needs Review; filter by Track Class, Configuration (well configured, or questions still open), or Detection. Well Configured counts a block with no question left open, and the card says so under the number. There are six questions: its name, its track class, its length, its maximum speed, its detection (a block marked dark territory has answered that one by design), and a signal. Maximum speed and signal are the two that are asked only of a block that has one: a block with no posted limit, and a block that owns no signal, have answered those rather than left them blank, so an unsignaled layout is not marked down for being unsignaled. The other four, detection included, are asked of every block, so a block with no sensors and no dark-territory flag has its detection question open. Under the cards, Questions Still Open lists each question with the number of blocks it is open on: that list, not the single number above it, is what to work from after an import, because one bulk action can close the same question on every block at once. Hovering a row's Config bar says how many of that block's questions are answered and names the ones that are not. A block whose saved configuration cannot be read is counted under Needs Review only, and appears under no question, because nothing is known about what it is missing; the card counts out of the blocks the page could read, and says how many it could not. Needs Review also counts a block whose configuration reads fine but holds something a block's governed configuration cannot carry: that block keeps its counts and its score, and its row says which part and why.
2. Click a block row to expand its inline editor and set Block Name, Track Class, Direction, Unit and Total Length, the foul length at each end (each end named as described under Block ends), This block's limit (mph), Restricted Speed, and the Electrified, Terminal, and Critical Section flags. Under those boxes the row shows the block's track speed and where it comes from (see Track speed): the limit you type only lowers it, and 0 or blank uses the track speed. A speed limit that came from a TrainController import is shown in the box under a "from the import" note: it is saved as your own value only if you change it, and emptying the box goes back to the imported one rather than leaving your last number behind. The same editor sets the block's Grade (%) and which way it runs (Level, or Rises / Falls toward one of the block's ends, named as under Block ends), and the Elevation at each end in the block's unit. A grade is saved only when you change it, a grade above 0 needs a direction, and emptying the grade box clears it. When RailCommand has measured the block at the layout, the row shows the measured length with who measured it, when (UTC) and on which computer; that measurement is used instead of the typed length, and Use the typed length removes it. The Layout Editor's block modal shows the same grade, elevation and measured length on its Block tab.
3. In the Block Detail panel edit governed Length (inches), each sensor's kind (point, current, flagman, delayed action) with debounce and memory (ms), and each marker's distance and ramp (inches: the fields carry an in suffix and match the Length field's unit; values are stored internally in millimetres, exactly, decimals and all). A marker whose distance plus ramp runs past the end of its block is flagged "past end of block". The Block Detail panel is labelled "Changes here save immediately" and auto-persists, unlike the Cancel/Save fields above. A sensor the block owns (one TrainController decoded as a block member, with no contact symbol drawn for it) also carries its address here: board, input and mode, checked by the same rule the Sensor Configuration page checks a drawn contact by, and the same rule again behind the DCC Address field the Layout Editor's cell properties panel shows for a drawn contact, so a board and an input accepted on one of those three surfaces is accepted on all of them and a refusal reads the same wherever you meet it. An empty board is allowed and says so: a sensor you have not wired yet reads Without Connection on the sensor table, which is an answer about the railroad rather than an error. Changing the board or the input drops the flat LocoNet number the import decoded, because that number named the old address and cannot be recomputed here; the panel says so when it happens, and the note stays while you keep editing. If the import decoded an address the rule would refuse, the panel says Needs review beside the fields when you open it, rather than waiting for you to type into a field that was already wrong. A sensor a block owns carries its namespace in its stored number, so Plain number is kept only while it has a board: choose Plain number with the board empty and the panel says so and asks for the board. Beside the address the panel offers the other resolution, place this sensor on a cell: choose a panel, a column and a row, and the sensor leaves the block's own list to become a feedback contact of its own, carrying its address with it, edited from then on like any contact you drew. The picker starts on the block's own panel, and a column or row outside that panel's grid is refused with the panel's size, because a cell outside the grid is not drawn. Where a block carries two sensors that cannot be told apart, because neither was decoded with a name, a board, an input or a number, placing one of them is refused and says so: give one of them a name or an address here first, and the two stop being the same sensor to everything that reads them. Neither resolution is forced, and a sensor whose occupancy is computed (a flagman) is offered neither, because it has no detector: its way out is a block rule, and each flagman row links to Webb, opened on that block and that sensor, to author one. Length is a single value: the Block Detail Length and the row's Total Length are the same measurement, kept in step whichever surface you edit (stored governed in centimetres, shown in the block's chosen unit). An imported block's decoded length shows in both without re-entry. Each sensor the block owns also says whether RailCommand on the desktop reads it as the block's detector: Detector: sensor 326 when it is bound, Not bound when it is not (import the layout again to bind it), and a point sensor is never bound, because it reports a train passing rather than a train standing in the block. The sensor number is (board minus 1) times 16 plus the input, the number the command station reports.
4. Click Save to persist the row fields.

Edit geometry and per-block settings from the Layout Editor:

5. Open /app/railcommand/layouts/{LayoutId}/editor. In Edit mode, double-click a block to open its Properties panel, then choose Open advanced settings… for the Block settings modal (tabs: Block, Block Editor, Speed & Rules, Conditions). In Simulate or Live mode, double-click opens the advanced modal directly. The Block Editor tab hosts the same Block Detail view, but changes here are staged with the rest of the modal: OK persists them and Cancel discards them. The Speed & Rules tab carries the block's rule flags — Release Rule, Routing Cost, Min Hold Time, Depart Delay, Permissive working, Out of service, and Dark territory (no detection by design). Drag-resize on the canvas or use the numeric span editor; both clamp to the geometry rule. A turntable or transfer-table cell routes through Properties to its own dedicated editor (tabs: General, Tracks, Connection, Display, Levels), not the block or turnout modal; its General tab also carries the authored physical startup position used by session-start reset. An indicator lamp cell (the band-15 indicator elements) routes the same way to its own small Lamp modal (display name, a colour for each state it shows: on, off and flashing, the state it starts in (off, on, flashing, or a colour steady or flashing such as red or flashing yellow), Flash when lit, and its Output: none, an accessory output, or a signal head output with each aspect mapped to what it shows: a colour, steady or flashing, off, on, flashing, or not used), and Open advanced settings… is the only path to it, because double-click opens the Properties panel rather than the modal. A lamp that was a signal also offers Turn into signal there. A signal's right-click menu offers Turn into indicator, and an indicator that was a signal offers Turn into signal. A push button, toggle switch or on/off switch opens its control dialog, whose Lit button section adds a physical button input (the sensor or contact address the real button reports on, so pressing it counts as a click) and a lamp in the button (lit while the control is on or pressed, unless a rule drives it); neither needs a track, a block or a cell.

6. Classify several blocks at once with paint mode. In Edit mode, choose the paint tool in the editor header (beside Select, Draw and Pan) and pick a brush: one for each Track Class, a Dark territory toggle, and an Unclassified (eraser). Click a block to paint it, or drag across several to paint each one. Painting acts on blocks, never on individual cells, so the brush paints whichever block owns the cell under the pointer. Keyboard: the arrow keys move a dashed paint cursor around the canvas, Enter paints the block under it, and . and , step forward and back through the brushes without leaving the canvas (the same two keys the desktop editor uses), and Escape puts the brush down and returns you to Select, keeping whatever was selected, which is what Escape does in the desktop editor too. The paint tool never moves your selection, and while it is active the canvas keys that delete, rotate, resize, copy and paste are switched off. Every stroke reports what it did, and names every place it could not paint. A drag writes one block at a time, so a block the editor cannot write does not undo the rest of the stroke: the blocks painted around it are saved, and the report names the one that could not be written and says so. Two brushes are worth reading before you use them: the Dark territory brush only turns that flag on or off and leaves the Track Class exactly as it was, and the eraser clears the block's classification, so the block and its track read Unclassified afterwards. A drag with the Dark territory brush takes its direction from the first block it crosses and writes that same state to every block in the stroke, so one drag turns the flag on (or off) across all of them rather than flipping each one separately, and the report says which way it went. Undo does not cover painting, so it is switched off while the paint tool is active: the editor's undo is for geometry (drawing, deleting, moving and rotating cells) and it carries no classification. To change a class back, paint the block again with the brush it had.

7. Painting track outside every block does nothing and says nothing: it is connector track between blocks, and a Track Class belongs to a block. To classify that track, draw a block over it from the element palette first (a Save also adds a dark block to any dead-end track still without one, and suggests one everywhere else, as described under Dark blocks for track with no block); the new block reads Unclassified straight away, with the dashed amber outline (on the desktop, on a layout you are editing online), until you paint it. On the canvas, a block with no Track Class is drawn with a dashed amber outline and a block marked Dark territory takes the neutral slate fill it wears during operation, so you can see which blocks CTC generation will refuse on without opening any of them.

In Edit mode the element palette is an overlay pinned to the canvas's left edge, so it sits on top of any blocks drawn there. Use the chevron in the editor header to collapse it and reveal those cells, and the same control to bring it back; leaving the editor is a separate Exit editor button, still guarded by the unsaved-changes prompt.

On the Layout Editor canvas, track is drawn at a line weight that follows its Track Class: Main is heaviest, then Branch, Staging, Interchange and Runaround, then Siding, Yard and Lead, with Industry spurs lightest. A cell whose class comes from its block inherits the block's weight, and a cell with no class resolved keeps the standard weight. This is an engineering-drawing convention and it is deliberately limited to the Layout Editor; the CTC dispatch panel keeps a single uniform weight for every class, because a period dispatcher's board draws to its own idiom rather than to a track chart. Changing a block's Track Class therefore changes how its cells are drawn on the editor, and never changes their weight, their dash or their colour on the CTC panel.

On a generated CTC panel the class does exactly two things: it supplies the label a block is drawn with when the block has no name of its own, and it sets the order the branches off one control point are placed in. The block's shape on that panel comes from how it connects in the layout graph and never from its class: connected at both ends it is drawn as through track, connected at one end as a stub, and a fan of tracks off one throat as a yard. So the same class is drawn three different ways on three different layouts, and a double-ended interchange or a through maintenance-of-way track is not drawn as a dead end. Every block with track on the chosen switchboards is on the generated panel: a branch leaves its control point by the turnout's diverging leg, drawn, and a passing siding climbs from one turnout and back down into the other. Track the panel has no room to join where it belongs is drawn on its own row, and the warnings say which; the only thing left off is an Exit with no track on the switchboard.

On the canvas, turntable and transfer-table cells render through the same shared cell-producer path as other special cells: the renderer reads each one's saved configuration through the shared resolver, so a turntable's ring and a transfer-table's tracks draw from their stored config rather than a block's geometry. A cell still flagged Needs configuration draws its placeholder until you complete it in that editor.

Hold blocks occupied after the detector clears (for cars without resistor wheelsets):

8. For the whole layout, open Layout Settings from the settings button in the Layout Editor's header and enter the seconds under Block Detection, Hold blocks occupied after the detector clears (seconds). Leave the box empty for no hold. A value outside 0 to 600 is refused with the range, and nothing is saved.
9. For one block, open its Block Detail panel (the Block Editor page's expanded row, or the Block Editor tab of the Layout Editor's block modal) and use Hold occupied after the detector clears. Use layout default means the block follows the layout setting. Set for this block starts at 0, which turns the hold off for this block; type the seconds you want instead. The Block Editor page saves at once; in the Layout Editor modal the change is saved with OK. The setting reaches RailCommand the next time the layout is downloaded.

Set a block's maximum train length:

10. For one block, open its Block Detail panel and type the longest train it takes under Maximum train length, in the block's unit (the unit its length is measured in). Leave it empty for no maximum. The Block Editor page saves at once; in the Layout Editor modal it is saved with OK.

Record mileposts:

11. For one block, open its Block Detail panel and type a milepost for each end and the center under Mileposts; press Use midpoint to take the center halfway between the ends. On the Block Editor page it saves at once; in the Layout Editor modal it is saved with OK.
12. To say how the layout numbers its mileposts, open Layout Settings and choose under Mileposts. For By distance along the track, enter the layout length of one milepost mile and its unit, the direction mileposts increase toward, and the starting milepost.
13. For the whole layout at once, open the Mileposts page, pick the tab, sort by Track order and choose where to start, then type down each column, pressing Enter after each value. Read the warnings under any block, then press Save.

Worked example: a 4-cell horizontal siding renders as a bar with one full-length current sensor and a Stop marker at its clearance point. Set the marker's distance in inches, save, and confirm the Detection column shows a green check.

Troubleshooting

CTC generation says it is refused, and lists blocks. Every block on the switchboards you chose has to carry a Track Class. The refusal names each block that has none, by its name (or by its position if it has none). Set the class on each block listed, then generate again. Track outside every block is never listed: it is a connector between blocks and needs nothing. A dark block the system added to a dead end (see Dark blocks for track with no block) is a block like any other, so it is listed until you give it a class. A block marked Dark territory is included in that list if it has no class: the marking says there is no detector, not what kind of track it is. A block you have taken out of service drops off the list at the next derive of the layout's graph: from that derive on, the generated panel does not draw it, so a class for it is not something you could go and fix. Until that derive it is still on the live graph and still listed.

Paint mode says a block could not be painted. The reason on the line is the one the layout's own write gave back, not a guess: a block deleted since the editor last read the panel asks you to reload the layout and paint again, and a cell that is not a block says which of the two things is true: the cell is inside a block, which it names so you can paint that block instead, or no block governs the cell, so there is nothing there to classify. A line that says the editor got no verdict for a block is a different case: nothing was decided about that block, so paint it again, and any block the same stroke painted before it is already saved. The same reason also appears as a red "!" badge on the cell it is about, and the next stroke clears it.

Ctrl+Z does nothing while I am painting. That is deliberate, and the paint panel says so: the editor's undo is for geometry, so it has nothing to reverse about a class, and undoing while a brush is armed would quietly reverse whatever you drew before you picked the brush up. Paint the block again with another brush to change its class; put the paint tool down and undo works as it always did.

The editor says a session is running on this layout and will not save a change. While an operating session is live on a layout, on any computer, its track diagram is locked: placing, moving, rotating or deleting cells, adding, resizing, reordering or deleting panels, changing a block's configuration, grouping signal heads, and placing a block's sensor on a cell are all refused, and the refusal names who started the session and when. The Layout Editor shows the same line in a banner as soon as it opens, and puts back anything the canvas showed before the refusal. End the session to edit the diagram: the banner's End session button asks you to confirm, then ends it for everyone in it, if you hold the session, are an organization Owner or Admin, or own the layout; anyone else is told whom to ask. A session that is paused or still being set up locks the diagram too. The roster, rules and hardware connection records are not part of the track diagram and are not locked by a session.

The cell properties panel shows a Track Class but will not let me change it. That is by design (owner ruling 2026-09-26): only a block carries a class. The panel says where the cell's class comes from, "From Block 'name'", and a block's class is changed in its details or by painting the block. Track outside every block and a turnout show None, because they carry no class. A layout imported before this ruling had its uniform track classes moved onto their blocks once, and a block whose track disagreed was left Unclassified and listed for the owner to classify.

I painted a class onto a block and nothing on the canvas changed. Check what the brush was. The Dark territory brush changes the detection flag only, and the eraser sets the block to Unclassified. If a class brush appears to do nothing, the block probably already carried that class.

A switch click in Simulate shows a red "!" badge, or a notification, instead of throwing. The editor recorded the command but the layout's simulated plant did not act, or the command was refused by the safety kernel; the notification says which. The badge clears on the next successful command on that cell. The page stays live: a failed command never terminates the editor session any more, and the fault is logged with the layout and the command so support can find it.

• Missing Detection (red ✕): the block has no resolved sensor. Add or resolve one in Block Detail; an unresolved indicator renders as a "missing sensor config" placeholder, never dropped. Two blocks never draw that cross: one you marked Dark territory shows a grey moon and reads "no detection by design", and one whose saved configuration could not be read shows an amber warning and reads Needs review, because in that case nobody knows whether it has detection.
• A block row reads "Needs review" with a reason: its saved configuration could not be read (for example it is not valid JSON), so its sensors, signals, limits and completeness are all unknown and the page reports none of them as missing. The Rules Debugger reports the same block with the same reason. Open the block in the Layout Editor and re-enter its configuration, or re-import the layout.
• A block row reads "Needs review" and still shows its counts: the block reads, and one part of it is in a shape a block's governed configuration cannot carry. The commonest is a marker added in the Layout Editor's Markers list or in the desktop panel editor beside the markers that came from an import: those are cosmetic, the operating engine's brake planner skips them, and the row names which marker and why. Expand the block to clear it. That marker has its own Needs review row in the Block Detail marker list, and the row carries both ways out: type a dist in inches, and a ramp if the train should slow into it rather than stop at it, to make it a real marker; or press Delete to remove it. Either one acts on that marker alone and leaves the markers that came from the import exactly as they were. The ramp box starts with the ramp that marker already carries, and leaving it blank keeps it, so typing a distance alone never turns a marker that brakes into one that stops. A marker you added in the Layout Editor's Markers list is still listed and still deletable there, and adding another one there never disturbs the imported markers. The Markers list and the Block Editor tab beside it edit one list: a marker you add, retype or remove in the Markers list is still that way after you clear a Needs review row on the other tab, and the row you cleared stays cleared. In the import preview, before the import is committed, the same row is read-only and says so: the block is not saved yet, and the two ways out are in Block Detail once it is.
• Imported blocks read "0 well configured", "no detection" and "no signals" on the Block page: fixed 2026-09-12. The page counted a block's sensors and signals from keys only the Layout Editor block modal writes, while a TrainController import writes the governed ones, so every imported block answered false and zero however much the import had decoded. Two of the eight things the page scored could not be filled by any import either, which kept an imported block off the Well Configured card on arithmetic alone. Blocks now count what they actually carry, including the per-block signals TrainController draws on no page, and the score asks only questions that can be answered. An already-imported layout picks this up the next time the page is opened; nothing is re-imported and no data changes.
• An unsignaled layout, or a layout with no posted speed limits, still read low on Well Configured: fixed 2026-09-13. Most TrainController layouts carry no posted limit on a block and are not signaled at all, and the score treated both as omissions, so those blocks could not reach the card however complete they were. "No posted limit" and "no signal on this block" are now answers: the question is not put to a block that gives them, and a block that has answered everything it was asked reads 100 percent. A limit typed by hand, or a signal placed on the block, is a question the layout does ask, and it counts. Nothing was loosened for a block that is genuinely unfinished: a missing name, track class, length or detection still counts against it, and Questions Still Open names which one.
• A block whose signals are both set to "None" still counted as having signals: fixed 2026-09-13. The block modal stores a hidden per-end flag that it switches on for every block it saves and offers no control for, and the page counted that flag rather than the signal TYPE you chose. A block with both ends set to None reported two signals, the score answered its signal question for you, and the Rules Debugger said the same block had no internal signals. The count, the No Signal card, the score and the Rules Debugger now all read the type you chose, so they give one answer about one block.
• A block still reads 83 percent and is not counted under Well Configured: that is the rule, not a rounding fault. Well Configured counts a block with nothing left open, so a block that answers five of its six questions is not on that card until the sixth is answered. Questions Still Open names it, and the row's percentage is the progress towards it.
• A change made in the Block Detail panel did not update the row's percentage: fixed 2026-09-13. That panel saves immediately, and only the surrounding Save used to re-read the page, so a length or a limit supplied there left the row and the Questions Still Open list showing the old answer until something else saved or the page was reloaded. The edited block is now re-read and re-scored as soon as the panel's change is stored.
• A block shows a maximum speed of 0: that is not a limit. The block runs at its class's track speed, and the score reports Maximum speed as still open on it rather than treating it as "no posted limit". A TrainController limit of 0 is decoded as no limit, so a 0 on the row came from somewhere else; set the limit, or empty the box to fall back to the imported value.
• "defaulted to current: confirm": the sensor kind was not imported. Confirm point vs current; an untouched default is never written back.
• "length not imported" / "position not imported: spaced by order": those values were not decoded. Set the length; a marker without a decoded position is placed by its order.
• "Sensors are shown in their order along the block. Their drawn sizes are not to scale.": this is a statement of fact, not missing data. A block's sensor order is what matters; TrainController let users draw a sensor at any size, so the drawn size carries no meaning.
• Blocks along the left edge are hidden and panning will not reach them — the element palette is an overlay covering that strip, not a cause of missing blocks. Collapse it with the header chevron.
• Deleting a panel will not delete the blocks and cells on it: that is the rule, not a fault. A panel that still holds any live cell is refused for deletion, and the refusal says how many it holds: move those cells to another panel, or delete them, and then delete the panel. Nothing you drew is ever removed by a decision you made about a panel. A layout also keeps at least one layout panel at all times, so its only one cannot be deleted; a CTC board does not satisfy that, because a board shows the railroad rather than describing it, so deleting the last board is ordinary.
• Cannot make a block 1×1 or diagonal — the geometry rule forbids it; the editor normalizes to a horizontal 2×1.
• "past end of block" on a marker — the marker's distance plus ramp is longer than the block. Usually a unit mistake: these fields take inches, like Length. A TrainController value typed as millimetres lands the glyph at the far left of the bar.
• Blocks you marked Out of service long ago have suddenly turned grey — expected, and the grey is the correct rendering. The web schematic reader looked for the flag under a different spelling than the editors write, so the Out of service checkbox has been inert on the schematic since it shipped; that mismatch was fixed on 2026-08-14. Any block already ticked out of service starts showing its out-of-service grey on the web schematic at that point without anyone editing it. Untick the flag if the block is back in service.
• A block shows out-of-service grey on the web schematic but looks unchanged on the Avalonia desktop: no longer expected. Both schematics drew the out-of-service state from 2026-09-06; before that only the web did, because nothing on the desktop projected the flag onto its render context at scene build. If the two surfaces still disagree on a build from that date onward, the block is genuinely different between them (check you are looking at the same layout and panel) rather than the desktop simply not drawing the state.
• A block has started showing the colours you picked in its Block settings: expected from 2026-09-06, and the colours are the correct rendering. The Display colours on a block (occupied, unoccupied, reserved, out of service) were written by the modal under one spelling and read by the schematic under another, so every block drew the standard palette no matter what you chose. Both schematics now read what the modal writes, and both draw all four. One difference is deliberate, and since 2026-09-25 it is the same on both schematics: a block whose detection has reported nothing yet draws the not-yet-reported look instead of your unoccupied colour, because nothing has reported that block clear. Reopen the block's settings and reset a colour if you would rather have the standard one back.
• A paint stroke crossed some track and said nothing about it. Expected. Track outside every block is a connector between blocks, and a Track Class is a property of a BLOCK, so there is nothing there for the brush to classify and nothing wrong with it. Draw a block over the track first if you want it classified.
• A paint stroke says the track is decommissioned. Expected, and no block is offered there. A decommissioned segment (ADR-0201) is not part of the live layout, so it needs no block and no class. Bring the track back into service first if it should be classified.
• The eraser cleared classes off the cells under the block, not just the block. Expected, and the brush says so before you use it. A block with no class of its own over uniformly classed track takes that class, so an eraser that stopped at the block would appear to do nothing at all.
• A block on the Avalonia desktop says it could not be painted, and names a cell. A cell inside the block is locked and carries a class of its own, so the classification could not be cleared. Nothing about the block was changed: a part-cleared block would read as the locked cell's class. Unlock the cell the message names, then paint again.
• The dashed amber outline does not appear on the desktop while a layout package is mounted. Expected today, and tracked as RailScanProUE#539. The block-level answer to "is this block classified" is the host's, and the mounted package projection does not carry it yet, so the desktop draws no marking rather than guessing and prompting you to fix blocks that are already correct. The block's properties panel says the same thing in words on that route: it reports that the package does not carry the block's classification, rather than calling every block Unclassified.
• A block is out of service and dark territory, and shows grey rather than the dark neutral — out of service wins. The display order is out of service, then occupied, then reserved, then not yet reported, then the dark-territory neutral, then free.
• A block shows a pale blue box with a dashed outline while a session is running: no detector has reported that block occupied or clear yet, so RailCommand does not know. It used to draw the web block in the free colour, which read as clear when nothing had said so. The block turns free, occupied or reserved as soon as its detection reports. A dark territory block never shows this, because it has no detector by design. Changed 2026-09-25, on both schematics.
• A block end shows a grey dot, or a grey dot in a dashed ring: grey means no dispatcher and no automation holds the block, so nothing decides whether a train may leave; this is normal when you run trains by hand. The dashed ring means the running session has not reported that end at all. A reserved or locked block shows the ring on the web until the exit indication is calculated there; an exit lock shows red.
• A block has only one end cap: its Direction is Left Only or Right Only, so trains may leave it by one end only. Change the Direction in the block settings to let trains leave by both.
• A block set to Left Only shows its one cap at its right or lower end: Direction names the block's ends in the order the layout stores them, and this block's order starts at its right or lower end. The cap is drawn at the end trains really leave by.
• The stop and brake markers are not on the board: no board draws markers, while you edit the layout or while it runs (changed 2026-10-06). Open the block's Block Detail panel, or its settings in the Layout Editor, to see and edit them. The Show block markers while running button is gone from the Layout Editor toolbar.
• A contact shows a grey dashed ring instead of a lit or dark lamp while a session is running: nothing has reported that contact on or off, so RailCommand does not know its state. On a live web board a contact lights from its own detector's reading, which the session's desktop sends; until a reading arrives, and while the desktop sends none, the contact shows unknown rather than off. In Simulate, a contact that reads a simulated block follows that block, and any other contact has no simulated detector, so it shows unknown rather than off, the same as in the desktop's simulation. Changed 2026-09-25.
• The desktop schematic's blocks changed colour: from 2026-09-25 the desktop draws blocks in the web's colours, cream when free, salmon when occupied and amber when reserved, with the block name in bold navy on the light colours, where it used to draw pale green, red and yellow tints. A block marked Out of service also stays grey while you edit the layout, on both schematics, instead of turning the editing blue.
• The Layout Editor modal's Block tab showed "Sensors (0)" and the name "Block" on an imported block — fixed 2026-08-18. That tab read a page-local copy of the block config whose field names did not match the governed ones the importer writes, so sensors, length and name all fell back to defaults. Worse, pressing OK wrote that default name back, renaming the block to "Block". The sibling Block Editor tab was always correct. If a block is currently named "Block" and should not be, rename it; the save path no longer blanks it.
• Sensor addresses read as flat LocoNet numbers — a General-Input contact on board 109, input 3 shows as 1731 ((board - 1) x 16 + input), the same form BDL168 wiring sheets and JMRI use. The stored value is shown as imported and never recomputed, so a contact whose import did not decode cleanly shows its board rather than an invented address. A Plain-Number contact also shows its board, because its stored value carries a synthetic offset that is not an address on any sheet.
• A sensor drawn as its own contact cell showed a blank address — fixed 2026-08-27. Those sensors keep their addressing on the drawn cell rather than in the block, and the import used to carry only the board onto that cell, so the address column had nothing truthful to show. The import now writes the board, the input and the flat value onto the cell, and one shared rule renders every sensor, so the Block Editor and the Layout Editor Block tab cannot disagree. A layout imported before 2026-08-27 does not pick this up by itself: the input is read from the TrainController file, so signing in or re-deriving the layout cannot supply it. Support can add it to the existing contact cells from the original file without a re-import, which would rebuild the panels and lose edits. A contact TrainController marked Without Connection still shows blank, because its stored address is stale and blank is the honest answer.
• The flat address shows only when it was imported — a sensor you address by hand shows the board and input you entered, with no flat number beside them. RailScanPro does not calculate one, because the inputs-per-board figure depends on the digital system (14 on an NCE AIU, 16 on LocoNet) and that system is not yet recorded against each contact. Calculating one anyway would print the wrong number for anybody running more than one bus, so the honest answer is to show what was decoded.
• A sensor listed under a block reads "no conn" and nothing could set its address: fixed 2026-09-13. Sensors TrainController decodes as block members have no contact cell, so the only editor they had offered kind, debounce and memory: the one property the sensor table flagged was the one property no screen could change, and the badge said the address came from the import. The Block Detail panel now carries that sensor's board, input and mode, the sensor table's row links straight to that field, and the badge names it. An already-imported layout picks this up the next time the block is opened; nothing is re-imported and no data changes.
• You would rather have that sensor drawn on the panel like your other contacts: use place this sensor on a cell in the same panel. The sensor leaves the block's own list, a feedback contact appears at the position you typed carrying its address (type it as TrainController shows it (row/column, counting from 1, for example 23/02)), and the block lists that cell as one of its occupancy sensors. An occupied square is refused with its position, and the layout graph is re-derived afterwards, exactly as it is when you add a sensor from the sensor table.
• Flagman sensor: its occupancy comes from TrainController logic. The import links each block's flagman to the flagman your file saved for it, so the block reads it with its other sensors (Block Detail says linked to the flagman your file saved), and translates the flagman's trigger into a flagman rule, listed on the layout's Automation rules page. While that rule runs, the sensor follows it; if the page lists it as disabled or held back, the sensor reports nothing by itself until the reason is lifted, and if you need it now, author a block rule (the panel links to Webb, the rules assistant).
• A block's flagman sensor says not linked to a flagman: its block reads unknown, so nothing runs into or through it, until one is linked. The import summary's Block flagmen line names each such block and why: its flagman was not imported, it is a virtual contact (which RailCommand does not read as occupancy yet), it is a contact whose address could not be read, or the import could not tell what it is. Only a member TrainController saved as a flagman becomes a flagman sensor; the others are listed as sensors of their block with no address and their TrainController ID, and a block with no other detector reads unknown until they are resolved. A layout imported before flagmen were linked shows this for every block flagman: import the file again. Otherwise ask Webb (the panel links to it) to author the block's occupancy rule.
• A milepost is refused where I typed it: it is not one RailCommand can read. Use up to three letters, then a number of miles from 0 to 99999.99 with no more than two decimal places, for example 123.4, B123.4 or MP 123.4. Nothing else in the save is affected on Block Detail; on the Mileposts page nothing is saved until every marked box is fixed.
• A warning shows under a block's mileposts: it is a second look, never a refusal. Check the value against the fascia. Not between the ends means the center is outside its two ends; may be swapped means the ends run the wrong way for the direction mileposts increase toward in Layout Settings; apart means the ends disagree with the block's length at your milepost scale, so an end, or the block's length, may be off.
• A milepost typed before these checks existed shows with a note saying it is kept as it is: it does not read as a milepost, so RailCommand does not send it to the desktop, and it is not changed until you type a new value.
• The Mileposts page offers no Track order sort: the layout's track graph has not been built yet. Save in the Layout Editor, which builds it, then reload the page.
• A train's cars stand in a block that reads clear (current detectors, cars without resistor wheelsets): set an occupancy hold for the layout or for that block, as described under How To, long enough for the slowest train to clear the block. The block then stays occupied after its detector goes dark until the time runs out or the train is seen beyond it. A block that holds when it should not has a value of its own or is following the layout default: set it to 0 to turn the hold off for that block alone.

Safety Notes

Blocks are authored and edited only on the web. Neither the web app nor the Avalonia desktop actuates hardware or drives trains — the desktop presents state and forwards operator intent, and the local/UE5 runtime owns all safety-critical execution (occupancy enforcement, interlocking, movement authority). Editing a block in the browser changes how the layout is modeled and displayed; it does not by itself power, move, or stop a train. During operation the occupancy recolour and the train tags are indications, not controls: a train's tag is drawn over its head block, a muted tail tag over the one block behind it when that is known, other occupied and reserved-ahead blocks recolour and keep their own names, and reservation is distributed before occupancy. A tag's arrow shows the way a moving train is travelling, solid moving forward and hollow with an R in reverse; a tag without an arrow means the train is stopped or its direction is not known (the tooltip says which), so never read a missing arrow as a stopped train. Never treat a cleared block indication as authority to move — confirm with the operating runtime and procedure.