RailCommand Hardware Setup

RailCommand Hardware Setup

Hardware Setup connects RailCommand to the DCC systems, sensors, accessories, and local runtime needed for live operation.

Before You Start

Confirm:

1. The physical layout is safe.
2. The correct operating layout is selected.
3. Track power and boosters are in the expected state.
4. Your command station, sensors, and accessories are connected.
5. You know where emergency stop is available.

Setup Flow

1. Open the RailCommand desktop app.
2. Select the operating layout.
3. Open Hardware Setup.
4. Run the system check.
5. Refresh hardware status.
6. Run hardware detection.
7. Add or edit hardware connections.
8. Confirm driver, name, connection settings, capabilities, primary flag, enabled state, and auto-connect behavior.
9. Start the session. Session Guidance is worth reading if a session produces less than you expect, but it is not a step before starting one; it has never been able to prevent a session from starting.

Health States

A command station is shared

A command station is shared by every computer that connects to it. RailCommand never describes a connection as held by a computer, and several connections to one bus are normal. The System Check reports a station as turned off, set to connect by hand, not answering, or in an engine fault. It never reports a station as in use by another computer.

The only exclusivity in the design is the role of acting as the command station (RailCommand generating DCC or mastering the bus). That role is future work, and no node holds it today, so no screen names it.

Troubleshooting

If hardware is not detected:

• Confirm the command station is powered.
• Confirm cables and network connections.
• Confirm the selected driver matches the hardware.
• Confirm no other software has exclusive control of the interface.
• Restart the local runtime only if your operating procedure allows it.

If an imported layout's connections point at the wrong port:

• COM port numbers belong to the computer, not to the interface. A layout imported from TrainController carries the logical buses that layout declared, never a port this computer assigned, and Windows can renumber the same interface after a replug.
• Run hardware detection and choose "Use this" on the detected interface. Hardware Setup offers the existing connections that speak the same driver so you can bind one instead of deleting it.
• Each offer says what it knows: a matching USB serial number means the same physical interface, an imported bus means no port has been assigned yet, and two serial numbers that differ mean a different physical interface. That offer names the last four characters of each serial number so you can check them against the labels on your interfaces.
• When at least one side recorded no serial number, the USB vendor and product ids can still settle it. If the ids the connection recorded differ from the ids the scan reports, the offer says a different physical interface and names both ids the way Device Manager shows them. Anything else is a re-point only you can confirm. Nothing is chosen for you, and nothing is saved until you save it.
• Binding changes only the port and the device evidence. The connection keeps its name, its primary flag, its enabled state, its auto-connect choice, its position, and every driver setting it was saved with.
• That includes the connection speed. A scan reports the speed a port enumerates at, which is not a reason to replace a speed you chose, so binding keeps the saved speed and a later scan never overwrites it. A connection with no speed recorded yet, which is how an imported bus arrives, takes the speed the scan reports the first time you bind it.
• If a connection's saved settings cannot be read, binding stops and says so instead of replacing them. The message names what could not be read, down to the individual setting, so you can open that connection and correct it. Settings nobody can read are the ones nobody can get back, so a scan is never allowed to write over them.
• A connection that reaches its command station over the network is rebound the same way, including a JMRI bridge addressed as a URL: detection reads the host and the port out of the address it found and leaves every other setting alone. An address that carries no host and port is not offered against a saved connection at all, and the screen names the address instead of offering a bind it would have to refuse.
• Capability roles are kept as you set them, on both ways of saving. A mounted layout saving to the local runtime used to be the exception, because the desktop sent the driver, name, port, and settings but not the roles, and the runtime then filled them in from its own driver registry. It sends the roles now, so narrowing a connection to fewer roles than its driver supports survives a save and a rebind, the same way it always did on a layout you edit over the cloud with nothing mounted.
• The one role limit that is not yours to choose belongs to the hardware. A feedback bus can only listen, so it cannot be given a role that sends to the layout: track power, loco control, turnout control, signal control, or programming. Ask for one of those on a feedback bus and the save is refused, naming the roles to untick. Detection and RailCom are things a bus listens for, so a feedback bus can carry them.

For manufacturer background, ask Casey about Digitrax, NCE, DCC-EX, Roco Z21, Lenz, ESU ECoS, TCS LCC/OpenLCB, or Marklin.

Next Steps

• RailCommand Session Guidance
• Starting a RailCommand Operating Session
• RailCommand Offline, Degraded, and Practice Operation