Rocrail and DCC-EX

Connecting Rocrail to a DCC-EX command station over TCP, what the client pieces do, and the settings worth getting right the first time.

Pillar

This write-up is still missing its first-hand detail

The general method here is sound, but the specific part numbers, readings and settings from the actual layout have not been filled in yet.

Rocrail is layout control software: a track plan, routes, block occupancy and automation. It talks to a DCC-EX command station over a plain TCP connection, which makes the integration refreshingly simple compared with anything involving a proprietary interface.

It is also a substantial piece of software with a long history and a dense interface. Expect the setup to take an evening.

The pieces

Rocrail splits into a server and its clients, and understanding that split makes everything else clearer.

  • Rocrail — the server. Holds the plan, runs the automation, owns the connection to the command station. This is the part that must keep running.
  • Rocview — the desktop client. The full editor; where you draw the track plan.
  • Rocweb — the browser client, served by the Rocrail server itself. Good enough for driving trains and throwing points from a phone or tablet.

You build the plan in Rocview, then use Rocweb day to day.

Connecting to DCC-EX

DCC-EX with WiFi accepts TCP connections and speaks its native text protocol over them. That is what Rocrail connects to.

In Rocrail’s controller settings, add a new controller and choose the DCC++ library — DCC-EX is the direct successor to DCC++ and uses the same command syntax, so this is the right choice despite the older name.

Then set:

  • Interface type: TCP (not serial, unless you really are connected by USB)
  • Hostname: the command station’s IP address
  • Port: DCC-EX’s network port — 2560 by default
Confirm the port against your own command station

2560 is the DCC-EX default, but it is configurable and has moved between firmware generations. Check what yours reports on the serial console at startup before assuming.

Save, restart the Rocrail server, and watch the server log as it connects. A successful connection shows the command station identifying itself with its firmware version. If you see a connection refused, the address or port is wrong. If you see a connection that opens and then goes quiet, something else already has the command station’s single connection slot.

The single-connection problem

This is worth knowing before it bites: a DCC-EX command station accepts a limited number of concurrent network clients, and older firmware effectively allows one.

If a throttle app is still connected on your phone, Rocrail may not be able to connect at all — or worse, may connect intermittently. When diagnosing a connection that “sometimes works”, close every other throttle first.

Addresses must match

Rocrail has its own locomotive list, and each entry carries a DCC address. That address must match what is actually programmed into the decoder. Rocrail does not discover this — it trusts what you type.

A loco that refuses to move under Rocrail but drives fine from a throttle is almost always an address typo in the Rocrail locomotive entry.

Set the speed step mode in the Rocrail loco entry to match the decoder too — see 128 vs 28 speed steps if the movement is coarse or the lights flicker.

Keeping it running

Rocrail started by hand from a terminal stops when you close the terminal, and does not come back after a reboot. On a machine that is meant to be a layout controller, that is not good enough.

Running it as a systemd service fixes both, and takes about ten minutes: Running Rocrail as a systemd service.

Reaching it from elsewhere

Rocweb over plain HTTP on the local network is fine at home. Reaching it from outside without opening a port to the internet is a separate problem, and Tailscale solves it neatly: Reaching Rocweb from anywhere with Tailscale Serve.

Where to go next

More on rocrail integration