Import a Layout from TrainController

Concept

Importing a TrainController project is how most operators create their first RailCommand layout. You upload a .yrrg or .yrl file (up to 50 MB) and RailScanPro builds a brand-new layout from it: the track plan, switchboards, accessories, and — optionally — your roster and trains.

The mental model is derived-not-stored. Your file is parsed into a staged preview; nothing is saved until you press Create. The graph, signal topology, and block wiring are not copied verbatim — they are derived when the layout is created. In between, you review the decoded objects in per-type Transform Tables and resolve anything the decoder flagged instead of guessing. Import is web-only — it always happens in the browser.

On the Blocks table, a block that decodes with no occupancy source at all — no wired contact and no flagman (computed) member — shows a dark territory? suggestion (#1618). Checking it marks the block dark at commit: no detection by design, occupancy not tracked, the dark-neutral display. The importer only ever suggests; it never assumes a block is dark.

Block detectors. A TrainController block usually senses its trains through contacts it keeps as block members, with no contact symbol of their own. The import binds each of those current sensors as a detector of its block, several per block where the block has several, so the RailCommand desktop reads the block's occupancy from them. Each detector binds at the sensor number the command station reports: on LocoNet and on an NCE AIU that is (board minus 1) times 16 plus the input, so board 21 input 6 is sensor 326. A contact drawn as its own cell binds at that number too. On the Blocks table the occupancy column lists each block's detectors by those numbers. A block with none reads no detector: automatic runs won't stop there until a detector is bound or the block is marked dark, because RailCommand refuses to run a train through a block it cannot see rather than guess. A block you mark dark on the table reads dark territory, and a block TrainController senses only through a flagman reads no wired detector, its occupancy coming from the flagman. The import links each block's flagman to the flagman your file saved for it, so the desktop reads it with the block's other sensors. The summary's Block flagmen line counts them and names each block whose flagman could not be linked, with why; that block reads unknown on the desktop until one is. A point sensor reports a train passing a spot rather than a train standing in the block, so it is not bound as a detector, and the import warnings name it. Open a block's Block Editor tab to see, for each of its own sensors, whether it is bound as a detector.

Maximum train length. Each block keeps the maximum train length TrainController saves for it (its Train Length / Maximum, the longest train it fits), in centimetres exactly as saved and separate from the block's own length: a block TrainController drew 99.06 cm long may take a 284 cm train. A block saved with no maximum (0) imports with none, and the 0 is kept with the block as TrainController saved it. A block whose maximum the import could not read imports with none, and the import warnings name it. The block's Block Detail panel shows the maximum and lets you change it.

Block speeds. Every block the file saves imports, whatever its speeds are: a number, a formula, or none. A block's speed limits come in exactly as saved, in km/h converted to mph without rounding. A speed TrainController saves as a formula is kept with the block as written and not evaluated, so that block has no speed limit of its own and the track speed applies; the import warnings name it, so you can set the limit in the Block Editor. A block saved with no speed has no limit of its own either. A block the import could read only from its own record, rather than from the whole file, is named in the import warnings, with its name, speeds and length marked as not verified.

TrainController files often leave track with no block (ADR-0271): sidings the file never blocked, track the panel drew between switches where there is no real track, or, in a file that decodes no blocks at all, all of it. A piece only 1 or 2 cells long between two turnouts, crossings or slips is part of their interlocking and needs none. Above the Blocks table, Dark blocks for track with no block lists a dark block for each other such stretch: dark territory, no sensor, address or signal, named B row:column after the stretch's first cell (furthest left, then highest; the name counts from 0 at the top left), with its panel, the stretch's position as TrainController shows it (row/column, counting from 1, for example 23/02), the track's cell count and why. Each row has an Include box. A dead end (a stub or spur that ends at a bumper, or where the track stops, and joins a turnout or other feature at its other end) starts checked. Every other stretch starts unchecked and reads Suggested: track between two turnouts or other features, a loop, and a piece joined to no turnout at all, because TrainController panels often needed track drawn between switches where no real track exists. Check a suggestion where the track is real, clear a dead end you do not want, rename any of them and tick Confirm dark. The commit adds the checked ones only, and the Warnings tab counts the suggestions. The blocks the file itself draws are imported exactly as drawn, and one drawn across a turnout or crossing is reported under the warnings rather than redrawn. If you exclude, move or resize a block on the Blocks table, the list can change at commit; the create-time summary lists every dark block the import actually added and every stretch it left as a suggestion. A suggestion left unchecked can be added later: save the layout in the editor, which lists the suggestions with an Add button.

A tiny leftover piece of track is stray track, not real track: 1 or 2 cells whose ends touch no other track, turnout, crossing, turntable or connector, with no block, sensor or signal drawn on them. A lone bumper symbol in the corner of a panel is the usual example. Above the dark blocks, Stray track lists each piece by panel, the row/column of its first cell and cell count, with an Include box that starts checked, and the Warnings tab counts them. Kept, a piece imports, and because it joins no turnout its dark block is only suggested. Clear Include to leave it out: its track is not imported, it gets no dark block, its row leaves the dark block list, and the create-time warnings name it. A piece of 3 cells or more is always real track, because a separate programming or display track is often drawn that way.

Track comes only from the cells of the file's switchboards, read the way TrainController saved them, so nothing that is not drawn track (a schedule, a dispatcher route, a template) can ever appear as track. If the file holds a TrainController object the importer can't read yet, the import brings in everything else but no track, and the review's Warnings tab opens with Track was not imported, naming that object. A file saved at an earlier TrainController project revision than the one the importer reads (426, the revision TrainController 10 saves) is one such case, and the warning names the revision the file was saved at: open the file in TrainController 10, save a copy, and import the copy. For any other object named there, send the file to support so it can be added.

The importer also reads the connection labels TrainController draws beside a panel's contacts — the text on an AIU-pin panel, for example. These are not a reviewable Transform Table row: they materialize directly as text cells on the matching switchboard panel when the layout is created, so you see them on the schematic rather than in the review. A label whose decoded position falls outside its panel's grid, or onto a cell something else already occupies, is named in the create-time warnings and left unplaced rather than guessed onto a cell — its text was read correctly, its position was not. Because this decoding happens while the file is parsed, a layout imported before it shipped does not gain the labels by re-deriving: the file has to be imported again.

Switchboard text labels import at the size they have in TrainController: a label you stretched across 32 cells there covers 32 cells here, and a label you stood on end reads top to bottom. The size is read from the file, never worked out from the length of the text. The Warnings tab opens with a Text labels line saying how many labels will import and how many at their TrainController size, with one row for each label that will sit on a single cell instead and why: its size could not be read from the file, or at that size it would cover something else on the diagram. Nothing is guessed for those; set their size in the layout editor after the layout is created. Contact labels on an AIU-pin panel always sit on the one cell beside their contact.

An address is an attribute of an object, never the reason it exists. The importer carries every switchboard object the file defines whether or not it is wired: a contact with no feedback address imports as an unwired contact (it activates by rules and operations), and the software-only objects (flagmen, counters, virtual contacts, pushbuttons and on/off switches) import as cells of their own kind with their names, positions and the operations TrainController bound to them. Those bindings, and the objects' triggers and conditions, are translated into the layout's automation rules (see Automation logic below). On the Sensors table the Kind column names each indicator's class. An object the file does not settle (its class could be more than one thing) asks you to pick the kind before you create the layout: on the Sensors table for an indicator (Contact, Flagman, Counter or Virtual contact), on the Controls table for a control (Push button or On/off switch). The choice is always yours; excluding the object is never the only way forward. A flagman or a counter TrainController put on no switchboard page still imports: it becomes a row in your Flagmen or Counters list, and the review says so on the row. Giving it a position adds a cell on a panel; it is not what makes the object exist. An on/off switch or push button TrainController keeps on no switchboard page (a club's "Magic" or "Auto" switches, for example) imports too, included by default, as a control with no panel cell: the rules from your file set and test it, and the RailCommand desktop lists it on the CTC board's Controls list, where you can turn it on or off or press it. Its row on the Controls table says so; giving it a position puts it on a panel instead, and leaving the row out leaves it out. Every other kind still needs a position before it can be placed. Nothing is ever given a made-up address.

What each state sends. A push button, an on/off switch or a toggle acts only in the states TrainController defines for it, and a state with no output is ignored, as in TrainController. A push button or on/off switch connected to contact 1 or contact 2 of an accessory address sets that contact while it is on (a push button while it is pressed) and sends nothing when it goes off, so a fascia button that throws its accessory when pressed does not close it again on release. A toggle sends the output its Output Configuration names for each state, and nothing in a state that names none. On the RailCommand desktop, contact 1 is the accessory's closed output and contact 2 its thrown output. A push button or switch set to Perform Operations runs its operations and sends nothing to the address TrainController stores for it. On the Controls and Toggles tables a One state ignored or Sends no output badge marks each such object; hover it to see which state. After the layout is created, the layout editor's Accessory output section on a push button or switch shows what each state sends, and you can change it there.

Turnouts wired the other way round. TrainController's Output Configuration also says which output each position of a turnout drives, and many layouts wire some turnouts so that the straight route is the thrown output. The import carries that to the RailCommand desktop, which then drives and reads each such turnout the way TrainController does. On the Turnouts table a Wired reversed badge marks each one; hover it for the outputs. A position TrainController gives no output is ignored: the desktop sends nothing for it and refuses a route that needs the turnout there. A three-way's outputs are not carried yet, and its row says Outputs not carried, so check that it moves the right way.

Counters import with the count your file had saved for each one (a counter whose saved count cannot be read imports at its start value, and the import report names it), and each one switches as it did in TrainController: on once its count reaches its Min, and off again above its Max (a Max of 0 means no upper limit). A counter RailCommand cannot hold as saved asks you for its start, switch-on and switch-off values, and says why: one whose Max is below its Min (TrainController never turns it on), one with a value above 2,147,483,647, and one whose Reset is not 0 (TrainController resets its count to that value but still counts down to 0, and RailCommand's counter has one start value for both). Answer them on the Sensors table, or exclude the row. The same question follows the kind you answer: if you settle an unsettled object's class as a counter, its window is asked for too, because nothing in the file typed that object a counter and nothing in it settles its start, switch-on and switch-off values either. Flagmen import with their name, their position (a name longer than 64 characters is read in full) and the operations bound to them. Their trigger and condition are translated into a flagman rule and their operations into rules on the flagman turning on and off (see below); a flagman's memory mode does not decode yet and comes across as the self-acting default rather than a guess. Each flagman row says as much.

Automation logic. TrainController stores conditions and triggers on many kinds of object: a flagman's trigger and condition, the conditions on turnouts, switches, blocks and routes, the trigger for each signal aspect, the Prerequisite steps of macros and operation lists, a schedule's condition and the condition on each of its sections, and a timetable entry's condition. The import reads every one of them. The Also in this file panel shows an Automation logic line with how many expressions were found and how many decoded; open it to see each object with one readable line per expression, for example a trigger that needs a block to be the current block and a counter to be on. A term the importer cannot read is kept and counted, with the reason, rather than guessed, and an object whose logic could not be read is named with the reason. On the Sensors and Controls tables the same lines show when you hover an object's kind or its Unwired badge. Schedule and section conditions in a file saved at a project revision before 416 are not read yet; the line counts them as expressions on no decoded object. A file saved at a revision the condition decode has no evidence for (TrainController 9 revision 316, for example, or one newer than 426) has none of its conditions read, and the line names the revision.

Automation rules from your file. When you create the layout, the import translates that logic into the layout's own automation rules, which run in the RailCommand rules engine: a flagman's trigger becomes a flagman rule, the operations bound to flagmen, counters, on/off switches, push buttons and contacts become rules on those objects turning on or off or being pressed, the operations of each action marker (a block marker TrainController saves with type 0) become rules kept exactly as the file saved them and held back, with their reason, until the RailCommand desktop runs action markers, each named macro becomes a macro (a Module) the rules call, each timetable entry becomes a rule on the model clock (its first time is the start and its second the end of the repeat, which it includes; a repeat whose end is not after its start runs on through midnight; an entry set to run on some weekdays runs on those days, and one set to a month and day, to never run, to a random extra delay or to a probability below 100% imports disabled with its reason), each signal aspect's trigger becomes a rule that sets that aspect (a signal that stands on no track, such as a light on the fascia, is named by its cell: when the review marks it "turn into indicator" its rules set the indicator's colour and run; otherwise they import disabled until you turn it into an indicator), TrainController's two-state display lights that have no connection (such as an "Automation Status" light) import as indicator lamps on the Controls tab and their rules set and test their colour, and a schedule's start, finish and section operations and its section conditions are attached to the schedule, and a step that starts a schedule starts it, as TrainController does, for whichever train stands in the schedule's start block (it needs RailCommand desktop rule schema 24, so until a desktop that reads it is released here the rule is held back). A schedule's operations that turn a locomotive function on or off (TrainController's train function operations, such as Bell On, Horn or Sound 2, directly or through a macro) become rules that set that function by the name your file's own function list gives it, which the desktop finds in each locomotive's decoder function labels, on the vehicles TrainController chose: the first, the last, every one, or the ones the train sends its functions to. TrainController's Random Delay becomes a random wait. A function rule needs a RailCommand desktop that reads rule schema 26, and a random wait one that reads 23, so until one is released in this environment they are kept and marked Held back. A construct that cannot run yet (for example a step that operates a function your file's function list does not name, names with text longer than 64 characters, or chooses the train's vehicles in a way the import cannot read yet, a function step run from a switch or flagman, which names no train, a step that sets or clears a TrainController route, which is not a route RailCommand operates, a step that runs the steps after it only by chance or in a random order, a test whose TrainController meaning is not proven, or a step that operates an object the file does not contain) still imports, as a disabled rule with its reason; nothing is left out. A condition that tests an object the file does not contain is different: TrainController skips that test, and so does RailCommand, so the rest of the condition decides and the rule runs. A group that counts how many of its tests hold (at least, at most or exactly a number) counts them as TrainController does, and a skipped test is not counted. A test is skipped only beside a test that is evaluated: when every test in a group of the condition names an object the file does not contain, the rule imports turned off with that reason, and a condition with nothing in it always holds. The review lists each skipped test with the rule it belongs to, and the create-time summary counts them. A trigger is different again: a trigger that tests an object the file does not contain, or that tests nothing, imports turned off with its reason, because TrainController never fires it and a trigger left on would fire as the session starts. The review's Also in this file panel has an Automation rules from your file line: open it to see, per kind, how many will run and how many import disabled, and the disabled ones grouped under their reason with what would enable them. The create-time summary has an Automation rules card with the same counts and a link to the layout's Automation rules page, which lists every rule, macro and schedule operation list with its status. A rule whose vocabulary needs a newer RailCommand desktop than the one this environment publishes to is kept, marked Held back with the desktop version it needs, and published once that desktop is released here. Importing the same file into the same layout again replaces the rules the last import wrote and leaves rules you made yourself alone.

Block end signals and locks (owner rulings 2026-09-26 and 2026-09-29). The import gives every block whose two ends the drawing orders its own exit signal at each end; TrainController has no entrance signals, so none are made. TrainController's own block signals (the two per block its dispatcher keeps, drawn on no switchboard) become those exit signals at the ends they govern, with their addresses; every other end gets a virtual signal (no hardware), which RailCommand signalling calculates. A signal of your file standing at a block end is never taken over: it keeps its imported logic, or the rule set you choose, beside the block's own signal. The create-time summary says how many of each, and which blocks got none because their drawing has no two ends. Conditions that test TrainController's calculated block signal ("the calculated block signal to the left is green") now read that end's own exit signal by colour, green for clear, yellow for approach, red for stop and white for restricting; "off" and the calculated distant signal have no RailCommand fact and import disabled with their reason. TrainController's lock and unlock of a block's entry or exit, and the tests of them, become RailCommand's block end locks: "entry to the left" is the entry at the left end. Both need a RailCommand desktop that reads rule schema 25, so until one is released here they are marked Held back; so are the virtual signals themselves, which a package carries only to a desktop that reads them.

Engines and trains. The Roster tab lists every engine and car TrainController keeps in its rolling-stock groups, with the kind TrainController gives it (steam, diesel or electric engine, freight or passenger car), and each engine's address from its connection. Whether a vehicle is an engine or a car is the class TrainController saves it as, so a vehicle whose model path names no kind still imports as an engine or a car, never as Other, and the import warnings name each one. The Trains tab lists TrainController's train sets and, as TrainController's own Trains list does, every engine that is in no train set as a train of its own, named for the engine. A car on its own never becomes a train. Each vehicle's maximum speed saved in TrainController becomes its Top speed in RailScanPro, in scale mph: TrainController saves it in scale km/h, and the import converts it to the nearest whole mph (a car saved at 40 km/h gets 25 mph). Each locomotive's decoder function labels come from the functions TrainController saves for that engine: the name is the one the file's own function list gives the function, and the number is the output TrainController saves for it, less one (output 3 is F2). A rule that rings the bell or blows the horn finds the function by that name. A function that runs the engine's own macro, a text function, one TrainController saves above output 29 (RailCommand sends functions up to F28), and a second function on a number or name already used are not given a label, and the import report names each one. A car has one maximum; an engine has one for each direction and takes the lower. A maximum of 0 sets nothing, and one outside 1 to 400 mph is left unset and named in the summary.

Turnouts: what the file does not carry. Two turnout settings TrainController keeps are not in the layout file, and the import report says so once each. Its Send switch OFF setting lives in RAILROAD.INI: RailCommand sends one command for each turnout and no OFF, so if your turnout decoders need an OFF after each switch, turn on Send OFF after the switch time for their connection on the Hardware Slots page. And each turnout's normal position is not read from the file, so imported turnouts show Not set until you choose one in the Turnouts table; RailCommand never guesses a position.

Schedules. Every schedule in the file imports as a RailCommand schedule when you create the layout: its name, its type (none, shuttle or cycle), its repeat count and its try-again time, its blocks with their start and destination marks, the directions each block may be used in and its critical section, waiting times and start delays, its whole diagram as a path graph (every link from block to block, including branches and circles; the run chooses its path when it starts), its legs when the diagram is one line from a start block to a destination block, its successors, and which trains may start it. A link or leg names no route: the routes its diagram names are checked against the layout's own routes at create and recorded, and RailCommand on the desktop runs a link directly between two blocks joined by track with no turnout between them. Across turnouts RailCommand on the desktop finds the way itself when the train departs, as TrainController does, over the track and turnouts between the two blocks and never through another block; it does not yet run such a link in a Shuttle or Cycle, or on a way that needs one turnout set both ways, such as a reversing loop. Any train in a start block may start a schedule, limited only by its Trains tab and its condition: a Trains tab becomes the schedule's train description, naming the vehicle groups and vehicles it lists (at least one vehicle of the train must be one of them, or every vehicle when the Trains tab asks for all of them, and a vehicle or group the tab marks excluded never counts), and those are found on the roster the same import brings in. An imported schedule opens in the Schedule Builder with its start, destination, blocks and legs, and its path graph. The Schedules tab, shown when the file has schedules, lists each one with its status (Imports enabled, Imports disabled, or Not imported), its start blocks, its destination blocks, a summary of its path graph, its links, and who may start it; the status is the one the create writes, after the translation of its conditions and operation lists. A schedule imports disabled, with every part the file gives it and the reason listed, when leaving something out would let it start or route a train where TrainController would not, or when it cannot run without it: a start condition on its Condition tab (RailCommand does not run a schedule's start condition yet), a section condition that cannot be translated yet, a Trains tab stored in a form the import cannot read yet, a section setting the import cannot read yet, a block the schedule marks as a destination only as an end block (TrainController accepts it only under its rule Use end blocks as destination blocks, which the import does not read yet), a block marked as a critical section in the schedule (RailCommand does not run critical sections yet; the mark is kept on the block's member), a schedule sequence or schedule selection (RailCommand has neither yet), or a file saved at a project revision whose schedule bodies the importer does not decode yet (it decodes revisions 416 through 426), which the note names. A schedule whose Trains tab names vehicles or groups stays disabled until the roster (trains and vehicle groups) is imported; if you create the layout without the roster, import it afterwards to enable those schedules. Operation lists (Start, Finish and the per-block entry, stop, continue and release lists) and section conditions that translate are attached to the schedule; one that cannot run yet is listed under Automation rules with its reason and does not disable the schedule (brake lists do not run yet). A start block keeps the direction TrainController starts it in: a block whose start arrow points left starts its train leftward only, and one whose arrow points right starts it rightward only. A block that only remembers a start direction, with no start arrow checked, is not a start block, and the review lists it as old data. A start block whose saved direction the import cannot read is not imported as a start block, and the review names it. The Rules tab (reservation, look-ahead, release and routing options) is not decoded yet, so RailCommand's defaults apply. The AutoTrain and Spontaneous Run templates and TrainController's internal records are not schedules RailCommand can hold; they are kept with the layout and listed on the tab. A schedule that belongs to a TrainController facility (a gradient, a hidden yard or engine shed, a hump yard, a line-up, a run-around or an engine change) belongs to that facility, which runs it; RailCommand has no facility runtime yet, so it is not imported; the tab lists it as that facility's schedule, and the create-time summary counts these schedules by facility. The import reads what each record is from the class TrainController saved it under; if it cannot read that, it does not guess: the record is not imported, the tab says its kind was not read, and the create-time summary counts it. Send the file to support so it can be read. At create, a block with no marker on the new layout also imports its schedule disabled, and the create-time summary names it. Importing the same file into the same layout again replaces the schedules the last import wrote and leaves schedules you made yourself alone. The create-time summary also names each imported schedule that meets dark track with no detection beyond it (a dark block that ends at a bumper, say), and the layout's Schedules page shows the same line under the schedule: a schedule whose last block is such dark track runs to the block before it and hands its train to the Dispatcher, for a crew member to drive it in by hand; a schedule whose only leg enters it, or a shuttle or cycle that would, cannot run automatically, and the line says to drive the train in by hand or end the schedule at a detected block before it. Nothing is refused on the website: the schedule still saves.

Variables. The file's variables import with the layout. A variable whose type the file settles (an object variable, such as one holding a train) also becomes a RailCommand variable; one whose value type the file does not settle is kept with the layout until that field can be read, rather than given a guessed Number, Text or Time type. Values import empty. The create-time summary counts both. TrainController macros import as automation macros (see above); cargo is not imported.

Label decoding is calibrated on files saved at TrainController project revision 426. A file saved at any other revision, a TrainController 9 file for example, keeps the fields between a label's text and its cell at different offsets, so the import reads none of its switchboard text or connection labels rather than place them on the wrong cells. The Warnings tab says so and names the revision the file was saved at. On such a file a missing label means not read, never that the layout has no labels.

How To

Prerequisites: a TrainController .yrrg/.yrl export (max 50 MB); you own the file or are authorized to import it; you are signed in as the organization that will own the layout.

1. From RailCommand Layouts (/app/railcommand/layouts) click Import from TrainController, or go straight to /app/railcommand/layouts/import/traincontroller.
2. Drag your file onto the drop zone or use Browse Files. Tick "I own this layout file or am authorized to import it..." (required), then click Analyze File. The file uploads and is parsed server-side; nothing is written yet.
3. Review the Transform Tables. One tab per object type: Turnouts, Toggles, Signals, Sensors, Blocks, Routes, Connectors, Controls, plus Schedules when the file carries schedules, Roster/Trains when the file carries rolling stock, and Warnings. Each tab badge shows its count. The header's "Also in this file" panel lists the file's automation logic (conditions and triggers, see above) and decoded facilities (Single Track Lines, Gradients and Shunting Areas: each becomes a Facility row on the new layout; their gradient percentages and endpoints follow in a later release once those fields are decoded) alongside roster/consist/geometry counts. Your TrainController vehicle groups import too, as rolling-stock groups on the layout, keeping their tree and their membership.
4. On each tab, use the include checkbox to keep or drop a row, edit fields inline (name, panel, DCC, aspects, speeds), fix a placement with the Row/Col field (type the position as TrainController shows it (row/column, counting from 1, for example 23/02); the old column-first 003:010 form is refused rather than guessed at), or use Add row to insert one. Panel and per-column filters narrow large tables; the footer flags any included row missing a position. Every count on this screen, tab badges included, is a count of the records decoded from your file, and the screen says so above the tabs: the configuration pages count the cells those records place once you create the layout.
5. Resolve the flagged uncertainty. On Roster, each vehicle shows the Connection TrainController records for it: "TC bus 1"/"TC bus 2" for a driven locomotive, "Without connection" for a conventional one. When your file lists two vehicles of one kind under the same name, both are imported: the first keeps its road number and name, the next has a number added to both ("83413-2", then "83413-3"), and the Warnings tab lists them. Each train member is joined to the exact vehicle TrainController records for it, so a train with one of two same-named cars gets the right one. A locomotive TrainController drives at a long DCC address imports at that address (TrainController stores "Engine 403" set to long address 403 as 100403). A long address below 128 has no RailCommand form, because RailCommand drives 1 to 127 as short addresses, so that locomotive imports with no address and a Needs a decision flag rather than reach the engine on the short address. A vehicle whose digital system the decoder could not determine shows a Needs a decision flag with the reason. Only a locomotive holds the create: untick Import for that row to leave it out, and the create unlocks. A flagged car is shown for information and can be left included; it has no decoder to drive, so it imports with no connection and does not gate. On Signals, any head whose facing the decoder could not determine shows a Needs direction flag: pick N/E/S/W (a suggestion is offered) or exclude the row. A signal whose decoded second DCC address breaks the consecutive pairing every TrainController file exhibits (addr2 = addr1 + 1) shows an Address pair? flag: keep the decoded pair (it is real, hand-authored hardware), edit the second address directly (an edit counts as an answer), or clear it to author later in the editor. On Trains, expand a flagged train and set the member's Dir to forward or reversed. A train can also name a vehicle you are not importing, either because the file has no roster row for it or because you left that row out: the member shows a needs a vehicle flag and its This vehicle column offers the two ways to settle it, point it at a vehicle you are importing or import the train without that vehicle. Every one has to be settled before create unlocks, because the alternative is a train quietly imported a vehicle short. Two answers are refused rather than taken quietly. If you leave out every vehicle in a train, the train would import with no vehicles at all: the flag stays, the row says so, and your way out is to point at least one member at a vehicle you are importing or to untick the train. And one vehicle is in one train: pointing two members at the same vehicle, in one train or in two, is refused with the reason, because the alternative is the same vehicle standing in two places at once. A vehicle here is the item itself, not the name a member looked it up under, so two roster rows that turn out to be the same vehicle count as one. The member that was refused is settled in its own This vehicle picker like any other: point it at another vehicle you are importing, or import the train without it. The picker only ever offers vehicles that are still free, which is neither a vehicle another train you are importing has nor one this train's own other members already name. On Train positions (shown when the file had trains parked in blocks when it was saved), each row names the train or single vehicle, the block, and which way it faced on TrainController's drawing (Faces left, Faces right, Faces up or Faces down, beside TrainController's own East or West). These are saved as the layout's TrainController starting positions: starting hints the desktop offers when you assign trains, which you confirm before anything is placed. A train you leave out of the import, or a vehicle you do not import, is skipped, except a one-engine train: left out, its position is saved on its engine, as long as you import the engine. A train still waiting for a decision on the Trains tab is saved once it imports. TrainController's West is the left or top end of a block and its East the right or bottom end, depending on how the block is drawn: on a block drawn left to right West faces left, and on a block drawn top to bottom (a turntable track, for example) West faces up. The saved facing is the block end that leaves in that direction on your layout's drawing. Two drawings cannot say which end is which, and there the position is still saved with its facing marked for review and the reason on the row: a block drawn as a single cell, as TrainController does on diagonal track, and a block drawn across several rows and columns, such as a turntable bridge. A train the import cannot find is listed and not saved. Nothing here blocks the create. On Controls, each turntable row shows its size on the diagram as TrainController stores it (for example Size 7 x 7 cells), and the turntable imports covering that many cells from its top-left cell; if that area would cover something else on the diagram, the row says so and the turntable imports on one cell for you to size in the editor. A turntable whose track ring the file does not give shows a Needs review flag for its ring size: set the track count (even 2 to 80 or odd 1 to 49) or exclude the row; the decoded fields are treated as unproven candidates, not defaults. On Turnouts, Toggles and Signals, an accessory (DCC) address on one digital system that included, wired rows of different kinds share (a turnout or toggle and a signal, such as a signal or lit button that follows a switch) shows a Shared address tag on each of those rows, naming every element on it. TrainController layouts share addresses on purpose, so each one imports on the shared address, operating one also sends that address's command to the others, and the tag never holds the create; the create-time warnings list each shared address under Addresses shared by more than one kind of element. If the sharing was a mistake, give one of them its own address. Several turnout symbols on one address are one machine (a crossover pair) and are never tagged. (Feedback addresses are different again: a contact number is unrelated to an accessory number, and many contacts legitimately share one feedback address as a single detection section, so sensors never raise this flag.) An address the importer refuses is flagged too: a switch or signal whose decoded address sits outside the universal DCC accessory namespace 1 to 2048 (on any digital system), or a sensor whose feedback value sits outside an encoding proven for its digital system (LocoNet General Input and Plain Number, NCE AIU) or on a system with no proven feedback encoding at all (a Märklin Central Station, for example), is never treated as a live address. On Turnouts the same needs-answer picker appears and hand-thrown (manual) is the only importable answer; powered is rejected with the reason. On Signals and Sensors such a row can be re-addressed (proven systems only) or excluded. A resolved row imports with no live address, and the refusal is named in the create-time warnings. A block whose embedded contact is refused imports without that contact, and a block contact TrainController itself left Without Connection is never imported as a live sensor. An NCE contact stored in the Plain Number form is refused outright (Plain Number is a LocoNet-family encoding; NCE feedback is AIU General Input only) and goes live only when you give it a cab (1 to 63) and an input (1 to 14), which converts it to General Input. Clearing Without Connection on a row is judged the same way as any other address going live: if the stored address is outside the range, the change is refused until the address is edited into range in the same step. A signal the importer cannot attach to any track shows an attached to no track flag: TrainController draws a signal in its own cell beside the run it governs and records no association, so the importer adopts the track under the signal or the one cell perpendicular to its facing, and a signal with neither would import drawn on the page protecting nothing. Answer it one of four ways: place it on a track cell (the picker offers the track cells beside it, and the Position field takes any cell), import it unplaced and marked, when it is a lamp on your fascia rather than a track signal turn it into an indicator, or attach it to track or a mast without moving it: pick a nearby track cell (the picker offers the track within two cells, diagonals included) and the signal stays where TrainController drew it while its mast attaches to that track, or pick a neighbouring signal and it joins that signal's mast as its next head. A join the importer cannot make (the signal is not beside it, or that mast already has three heads) is flagged rather than taken. Above the tabs, the list of Signals attached to no track groups them by panel, largest first, with one-click answers for a whole panel: Import as lamps (a fascia or signal-board panel) or Leave unplaced, and Import all as lamps or Leave all unplaced when more than one panel has them. A one-click answer is sent in one step, takes only signals still unanswered or given the other one-click answer, and never replaces a signal you placed on a cell, attached to track, or joined to a mast. A signal turned into a lamp keeps its address, its aspects as lamp colours, and its imported logic, which then lights the lamp. A signal that attaches to no track and shares its accessory address with a turnout or toggle is taken as that switch's lamp (a lit button): it arrives already answered turn it into an indicator, its Belongs to column says Lamp for and names the switch and address, and you can change the answer if it is a track signal. A signal answered as a lamp is never asked for a facing, because a lamp has none. A signal TrainController draws with its stacked head image in the cell beside another signal (a second head on the same physical mast) is never asked about: it shows a head 2 on a mast flag and imports as that mast's second head, keeping its own name, addresses and aspects and drawn where TrainController drew it, and the mast attaches to the track beside either of its cells. A head you joined yourself shows the same flag with Undo. Answer the facing first, because the facing decides which sides the importer may adopt from. A signal's facing is the way its face points (TrainController's rotation 0 faces west), and it protects the track behind its face. The Belongs to column on the Signals tab says what each signal belongs to, worked out from the drawing in your file: a block end, as the signal trains pass to leave that block (exit) or to enter it (entry, with the switch on its face side as its approach), or a switch it protects (approach, from the leg a train reaches it by). Looking the way the signal faces, a block before any switch makes it that block's exit; otherwise, looking the way it protects, a block first makes it that block's entry; otherwise it approaches the first switch it protects. A signal the drawing attaches to nothing says why, and its picker lists the block ends and switches drawn within about 20 cells to choose from; any other signal's picker offers the same choices, and As worked out from the drawing keeps the importer's. A second head (the stackable image TrainController draws beside a signal) shows the answer of the signal it belongs to, and a choice on it changes that signal. Every signal's picker also offers Not a track signal: import as an indicator (lamp), for a lamp on the fascia whether it is drawn beside track or away from it: it imports as an indicator that keeps its address, its aspects lighting the lamp. A signal your file does not draw says so, and has nothing to choose: a block's own signal imports with its block, and any other one imports once you give it a position. The panel under the header banner counts the signals by what they belong to and lists the signal bridges, rows of signals across parallel tracks facing one way. The Logic column chooses how each signal's aspects are decided: Imported logic, the default, where the rules imported from your file set the signal green, yellow, white or red as TrainController did, so the layout behaves as it did (the first state whose rule holds is shown, in TrainController's order green, red, yellow, white, and when none holds the signal shows its state with no rule, usually red); or RailCommand signalling, where RailCommand works the aspects out from what the signal belongs to and the signal's imported rules are kept but not run. The panel's All signals buttons set every signal at once. Below the header banner, Signals attached to no track lists every such signal with its panel, cell, DCC address and aspects, and the answer you gave, so an unnamed signal can be recognised by the address you wired. A mast imported unplaced is still imported: it is drawn where TrainController drew it and carries the flag on the layout's Signals configuration page, so a signal that protects nothing is never silent. A signal you turn into an indicator becomes an indicator lamp as the layout is created: it stays where TrainController drew it with its name and addresses, its head's outputs light the lamp in colour (a 4-aspect head's aspects show green, red, yellow and flashing yellow in TrainController's order, and the lamp starts red; you can change any of them in the lamp's settings), and it is never a signal, so it is not reviewed as a mast that protects nothing. The results page counts the signals turned into indicators. The importer flags rather than guesses; every included flag must be cleared before you continue. Import warnings also call out off-page connectors that cannot pair: one with no branch label, or one whose label no other connector shares (a jump that goes nowhere until its mate is drawn). These do not block the import, but they are the list of panel joins your drawing still needs. When you import into a layout you already have, the Turnouts tab opens with Your turnout settings where the file and your layout disagree and the import cannot tell who changed a setting, or you both did: each turnout shows your value and the file's for every such setting, and you choose Keep mine (the default) or Use the file's, one turnout at a time or for all of them. A setting only you changed since the last import is kept without asking, and a change in the file you did not make is taken. A turnout's milepost is yours alone: no import writes one, so it is always kept. The Blocks tab opens the same way with Your block settings for a block's name, length, maximum train length, dark territory answer and speed limits. A speed limit asks only when you set your own and the file's limit changed too; the file's own limits (and its speed formulas, kept as written) always come from the file, and Use the file's removes your limit. A block drawn on more than one panel takes its settings from its first panel in board order, the one the layout runs on, and the import writes them to every panel; where another panel showed a different value, the review and the report name it. Every other block setting you made that the file does not carry (mileposts, hold time, measured length, grade, foul lengths, elevations, the block's class, division and aspect paradigm, rules, display and signal settings, and the rest) is kept without asking. The Roster tab opens the same way with Your vehicles: engine or car, Top speeds and function labels when a vehicle already in your inventory is a car here and an engine in the file (or the other way round), or has a Top speed or a decoder function label that differs from the file's and the import cannot tell who changed it, or you both did: you choose Keep mine (the default) or Use the file's, one vehicle at a time or for all of them. Choosing the file's engine or car also changes the vehicle in the trains it is already in, so a train whose engine an earlier import left as Other is led by it again; keeping yours leaves it as it is, and the import report names it. A vehicle imported before the import read Top speed, whose Top speed is still empty, simply takes the file's, and so does an empty function label on a locomotive imported before the import read its functions.
6. Answer How will you run this layout? above the Create button. Run trains (like TrainController): open RailCommand and drive is selected for you: you open RailCommand on the layout and drive, the way TrainController worked. Choose Operating sessions (clubs and museums: crew, dispatcher, car forwarding) if you run formal sessions with a crew. You can switch to operating sessions at any time from the layout's page. A re-import does not ask: the layout keeps how it runs.
7. Click Create layout (it shows the object count). The graph, signal topology, and block wiring derive at this step, and the summary reports what materialized, including every dark block added to track with no block, the stretches left as suggestions, and any imported block drawn across a turnout or crossing. Its turnout and signal lines count the records decoded from your file. The Turnout Configuration and Signal Configuration pages count the cells those records placed on your switchboards, which is a different population, so the summary states both numbers and itemizes every difference between them: toggles, which materialize as on/off switches rather than turnouts; records that share a position with a cell already placed there; records the file gave no switchboard position; hand-thrown switches and turntables, which hold a turnout cell no record produced. A difference the import cannot account for is reported as not itemized rather than being given a reason it did not establish. The DCC addresses are counted and itemized the same way, because they are a population of their own: a switch the file marks Without Connection keeps a stored address the file itself calls stale, so the import never stamps it on a cell, a toggle's address belongs to the on/off switch it materializes in the Control band, and a record that got no cell had nothing to carry an address. That is why a summary can report 231 decoded addresses beside a Turnout Configuration page reading 180 addressed, with every one of the other 51 named. A switch whose stored address reads 0 has no address at all, because DCC accessory address 0 does not exist on any command station: it imports as a turnout like any other, it is not one of the decoded addresses the summary counts, and its cell shows no address until you set one. When some of the file's vehicles did not import, the roster line names how many the file carried beside how many were imported and itemizes the difference, so a small number is explained rather than surprising; when every row in the file imported there is nothing to explain and the line is not shown. A train the import could not build exactly as the file describes it is listed with the vehicles it matched, the vehicle it is short of, and what happened. That screen reports; it cannot take a decision. To create a refused train, import the file again and answer on the Trains tab, or build the train by hand on the Trains page. Each resolved turntable's ring materializes onto its placed cell as the turntable's behavioral config, flagged Needs configuration so you can finish it in the editor. The summary also says what the signals belong to (block exits, block entries, switch approaches, any not attached, and the signal bridges) and how many signals use imported logic and RailCommand signalling; the Signal Configuration page shows each signal and lets you change either. The Train positions card counts the starting positions saved, how many need their facing checked, and how many were not saved (each named in the warnings). A re-import replaces the layout's TrainController starting positions; the layout's Trains page lists them with the file and date they came from. The Validation card lists the import's notes by kind: each kind says what it means and whether you need to act (Action needed or No action needed), and opening a kind lists every note of that kind, none capped or hidden. Kinds that need you come first, such as hardware connections to finish, addresses not imported as live, or positions read without a second check; notes about records that are not track you drew, or counts of what the importer read, need nothing. A note no kind describes is listed under Other notes and asks to be read. A re-import's summary also lists Your turnout settings: for each turnout, every setting it kept, took from the file, or settled by your answer, with both values. A change of address is reported only once its hardware binding moved with it; one it could not apply, for example because its bus is new to the layout and was not set up, is shown in amber with the reason, and your address stands. The summary also names any turntable whose run routes or hardware bindings need it chosen again, because a turntable carries nothing in the file that lets a re-import recognize it. The Rolling stock card says how many vehicles took their Top speed from the file (open the line for the list), what a re-import kept, took or settled by your answer for each vehicle whose Top speed you had changed, and names any engine whose forward and backward maximums differ and any saved maximum outside 1 to 400 mph.

Troubleshooting

"Invalid file type" or "File size exceeds 50 MB" — Only .yrrg/.yrl files up to 50 MB are accepted. Re-export a fresh project from TrainController.

The file was refused for how far it expands: a .yrrg is a compressed archive, so a small upload can hold an enormous amount of data. The importer reads to a fixed budget and stops, rather than trying to hold whatever a file claims to contain, and a file past that budget is refused by name instead of failing partway through. No real TrainController layout comes close: the largest in our corpus decodes to about 7 MB against a budget of 128 MB. If you see this on a genuine export, the file is worth sending to support rather than re-exporting.

Create layout is disabled with a lock reason — An included signal still needs a facing or attaches to no track, or a train member, turntable, or row still needs attention. Follow the amber "Signals tab" / "Trains tab" / "Controls tab" link, pick a value or exclude the row, then create. The server re-checks these gates on create, so clearing them in the review UI is not optional.

Two of my signals share one mast, but they imported as two separate signals — That is correct and deliberate. TrainController has no multi-head mast: every signal in a TrainController file is a single head, and a two-head mast is drawn there as two separate signal objects in neighbouring cells. There is nothing in the file that says "these two are one mast", so import never guesses at it and never asks you about it — every imported signal arrives on its own. Building the mast is an editing step: select the heads in the layout editor and group them (and ungroup to split one again). A mast in RailCommand is one cell carrying several heads, which is a stronger model than the drawing trick it replaces.

I used to be asked a "Multi-head?" question during import — It is gone. That question assumed TrainController could express a shared mast; it cannot, so the question could never be answered from the file and has been removed rather than given a default. Nothing about your import is being silently decided instead: signals import solo, which is what the file actually says.

A turntable is locked "Needs review" — Its ring size was decoded as an unproven candidate, not confirmed. Set the track count (even 2–80 or odd 1–49) on the Controls tab, or exclude the turntable, to unlock create.

A locomotive is flagged "Needs a decision" on the Roster tab: TrainController records, per vehicle, which digital system drives it. That is what binds an engine to the right command station, so an engine whose system could not be read is never given one at random: untick Import for the row to leave it out, or fix the engine's Connection tab in TrainController and re-export. A car can carry the same flag: the connection is read the same way for every vehicle, so a car whose connection could not be read is flagged too. It never blocks the create, because a car has no decoder to drive and no output binding is written for it. Leave a flagged car included and it imports normally, with no connection and with the uncertain address dropped; only locomotives have to be answered or excluded.

My N-scale engines are on the wrong bus after import: Re-import the file. The import reads each engine's own Connection tab and binds it to the matching TrainController bus on this layout, and a re-import updates the existing assignments in place rather than duplicating them. The summary reports the result per bus ("4 locomotive(s) bound to TC bus 2"). If a bus connection was created by an earlier import and cannot drive locomotives, the re-import switches locomotive control on for it; nothing else about the connection changes, and it stays disabled until you enable it.

A refresh sent me back to Upload — The staged review lives only in your session, so refreshing or leaving discards it. Re-upload to restart — nothing was written to your account.

An included row didn't appear after Create — A row flagged "N need a position" does not materialize until it has a row/column position.

The desktop shows no occupancy for a block, or refuses a schedule because a block has no detector, on a layout you imported before block detectors were bound: expected on those layouts. The import then bound none of a block's own sensors as its detectors, and it bound each drawn contact at its board number instead of its sensor number, so the desktop listened for the wrong sensor. Import the file again to bind them. A re-import rebuilds the layout's panels: it keeps the turnout settings you changed since the last import, and asks about any the file also changed, but other edits made since then are lost; nothing changes those layouts without a re-import.

A block's stop or brake marker names no sensor, on a layout imported before markers named a block's own sensors: expected on those layouts. A marker measured from one of the block's own sensors (the sensors TrainController keeps in the block, with no contact drawn for them) was linked to no sensor, so the desktop could not run it. Import the file again: each such sensor now has its own identity, bound to its input as a sensor of its own, and the marker names it. The same holds for a marker measured from one of the block's flagmen, or from a contact TrainController saved with no connection (which stays one of the block's sensors, with no address): import the file again and the marker names it.

A sensor is locked with "Imported with block" — Expected: block-embedded contacts import their occupancy with the block, not as standalone sensors.

A contact drawn as its own cell now imports its full addressing: Since 2026-08-27 a feedback contact TrainController drew as a separate cell carries its board, its input and its flat LocoNet value onto that cell, so its address shows everywhere the block's other sensors do. A layout imported before that date kept only the board on those cells, and signing in or re-deriving the layout does not add the rest: the input is read from the TrainController file, not from anything RailScanPro already holds. Do not re-import to get it, because a re-import rebuilds every panel and loses your edits other than turnout settings. Support can add the input, the mode and the flat value to the existing contact cells from the file you originally imported, changing nothing else, so contact support with that file.

Cross-checking a sensor against a BDL168 sheet or JMRI — the Sensors tab's read-only LocoNet column shows the flat address as imported (LS1731), the same number JMRI displays and BDL168 planning sheets print. Address and Input are the same sensor in board/channel form: LS1731 is board 109, input 3. The column shows — for a Plain-Number contact, which has no flat LocoNet address.

My AIU pin panel imported, but none of the pin names came with it — the pin addresses have always imported; what was missing was the labels TrainController draws next to them, and those now decode. If your layout was imported before that shipped, re-import the file — a re-derive cannot add them, because the labels are read while the file is parsed. If a fresh import still brings no labels, check the Warnings tab for the legacy-field-marker warning below: on an older file the labels may not decode yet, and that is a gap in our decoder, not an empty panel.

The import warned that the switchboard text labels were not read: the file was saved at a TrainController project revision the label decode is not calibrated on (it reads revision 426 only), and the warning names that revision. The importer reads no label at offsets it has not measured, so the file's switchboard text and connection labels did not come across. Nothing here is the operator's mistake: report them as not read rather than absent, and escalate the file.

A decoded label is missing from the panel after create — check the warnings reported with the create result. Two cases are named there: the label's decoded cell fell outside that panel's grid (the cell offset is not yet decoded for the Symbol/Image label variants, so the text is right but the position is not), or it collided with a cell already on that square. In both cases nothing is guessed onto the canvas; place the label yourself in the layout editor. A label that never appears in either warning may not have decoded at all — that shows up earlier, as a parse warning on the Warnings tab, not with the create result.

Labels or a turntable from an earlier import are squeezed into one cell: layouts imported before the sizes were read from the file put every text label and turntable on a single cell. Importing the file again brings them in at their TrainController size. If you have edited the layout since and do not want to import again, ask support: a one-time pass can size them from your original TrainController file, and it leaves alone anything you have already resized.

A turntable in my file isn't on the Controls tab — If the decoder could not recognize a turntable-shaped object it surfaces it on the Warnings tab rather than dropping it silently. Recognized turntables import per-instance, so a multi-turntable file yields one reviewable row each.

The import summary and the configuration page report different counts (for example 231 turnouts on the summary and 226 on the Turnout Configuration page): both numbers are right, and they count different populations. The summary counts the turnout and signal records decoded from your file; the configuration pages count the cells those records placed on your switchboards. They are not meant to be equal, and the import does not force them: the summary's turnout and signal lines state each count and itemize the difference reason by reason. A toggle is a decoded turnout record that materializes as an on/off switch, so it is never a turnout cell. Two records drawn at one position share one cell. A signal the file gave no switchboard position cannot be placed on a panel at all. In the other direction a hand-thrown switch and a turntable each hold a turnout cell no record produced. Read the itemized line on the create-time summary before treating a difference as a loss; anything the import cannot account for is named not itemized there.

The summary says 231 DCC addresses and the Turnout Configuration page says 180 addressed: same shape, one level down. The summary counts the addresses your file holds; the page counts the addresses standing on cells. A switch TrainController marks Without Connection carries a stored address the file itself treats as stale, so it is imported as a hand-thrown switch with no address, which is also why the page's Manual count rises by the same switches. A toggle's address goes to the on/off switch it materializes in the Control band, and a record that got no cell had nothing to carry an address at all. The create-time summary states both numbers and names each of these groups by count. To make a Without-Connection switch live, clear Without Connection and give it an address in range on the Transform Tables before you create the layout, or set its address on the Turnout Configuration page afterwards. A switch whose stored address reads 0 is counted on neither side: 0 is not a DCC accessory address, so the switch imports with no address, and the Turnout Configuration page's address editor is how you give it one.

The layout imported, but the desktop engine reports 0 signals and 0 turnouts: since 2026-08-28 the import also derives a hardware binding for every addressed element, each on its own decoded digital-system bus (never a guessed slot), which is the shape the operating engine mounts signals and turnouts from. A fresh import needs nothing extra. A layout imported before that date does not need a re-import: applying the bindings step re-reads the same .yrrg and writes only the missing bindings, so post-import edits are kept. Elements TrainController stored as "Without Connection" or with no address stay unbound on purpose; they exist, display, and compute, and can be bound by hand later. A bus whose TrainController driver had no confident RailCommand mapping leaves its elements unbound with a named warning instead of guessing.

Signals imported, but some of them protect nothing: a signal only protects a block when the importer can attach it to the track graph, and TrainController records no association between a drawn signal and the run beside it. Any signal the importer could not attach is flagged at review, and any signal that is attached to no track carries an attached to no track flag on the layout's Signals configuration page, whether the import left it that way or an edit detached it later. Place it on the run it governs in the Layout Editor, or import the file again and place it on the Signals tab. The chip is a live reading of the layout rather than a record of the import: it clears once the signal attaches, and it appears on any signal that is detached later.

Only a few roster items imported, and a train is missing: the summary's roster line says what the file carried and where the rest went (not selected, ambiguous, deleted while the import ran, failed). A train imports only when every vehicle it names is a vehicle you are importing: if one is not, the train is listed as needing review with that vehicle named, and it is not created until you point the member at a vehicle you are importing or import the train without it. Two more cases are listed the same way and refused the same way: a train you left every vehicle out of would import with no vehicles at all, and a vehicle another train in the same import already has cannot be in this one too. The completion screen reports these; it cannot settle them. Import the file again and answer on the Trains tab, or build the train by hand on the Trains page.

Some of my TrainController schedules imported disabled: each one says why on the Schedules tab of the review, and the create-time summary counts them. The common reasons are a start condition on the Condition tab (RailCommand does not run it yet; check the condition, and turn the schedule on only if it may start without it), section conditions and section settings the import cannot read yet (kept for the rules translation), a Trains tab whose vehicles or groups are not on the imported roster (import the roster to enable it), and a diagram in which no start block reaches a destination block. A Trains tab limit and a diagram with several paths do not disable a schedule: the Trains tab becomes the schedule's train description, and the run chooses its path when it starts. A disabled schedule keeps its blocks, links, legs and successors; it stays off until what it needs is supported or you finish it by hand.

Rolling stock is missing — Confirm "Import rolling stock & trains with this layout" is on, or import it later from Asset Management at /app/asset-management/import.

Safety Notes

Import is a web-only authoring action. The ownership attestation is required for legal reasons, and the whole flow runs in the browser — it never actuates hardware. Creating a layout writes a definition; it does not energize track, throw a turnout, or drive a command station. The DCC addresses, aspect counts, and switch times you enter are stored configuration only.

Running the layout happens later on the RailCommand desktop, which presents state and forwards operator intent; the local/UE5 runtime owns all safety-critical execution — interlocking, movement authority, and emergency stop. Correct addresses and facings at import make that runtime correct, but neither the web nor the desktop UI actuates hardware itself.