Can DCC railroads be controlled by computers?

Check out .
Ignoramus322 wrote:

Awesome, just what I need. I also donated $10 to them.
i

Ignoramus322 skriver: As mentioned - JMRI.
I have just bought a SPROG II USB for controlling and programming of a very very small DCC layout (1 meter of track - I'm building decoders into locomotives for different people). I've just started with DecoderPro ( a part of the JMRI Package) and it seems easy to use. You need somethig to interface between your computer and your railroad...
Klaus

Check out the Model Railroad System Yes, it is possible to 'speak' to a DCC system directly from a computer. I have written a library to interface to XPressNet, Lenz's 'network' for their DCC system. Lenz makes a RS232 XPressNet 'box' -- jack the RS232 into your PC and the other end into the Lenz XPressNet (which should include at least a command/booster station), and there and you can start sending command and receiving responses with your commputer. The computer can replace any number of throttle units. *I* plan to use a RailDriver console to control trains. Posibly a (Ethernet/Wireless) LAN of hacked laptops with RailDriver consoles, with a cental (boss/dispatcher) system that monitors block occupancy, OS sections, and speaks to the DCC system to actually controll the trains. I believe the JMRI can do this too (jmri.sourceforge.net), but needs Java installed...
It is also possible to build a DCC system *from* scratch and replace the 'command station' completely with a computer -- all you would need would be one or more boosters (and decoders).
Command station: generates the DCC command signals from some source (eg throttle units).
Booster: overlays the DCC command signals on the raw 16-18VAC source power creating a +/-12V square wave power signal across the tracks.
Decoder: decodes the DCC command signals from the +/-12V square wave power signal across the tracks and rectifies the power itself and drives the motor and accessories (lights, sound, etc.). Most decoders ride in locomotives, but there are also 'fixed' decoders for fixed accessories (like turnouts or signals and the like).
Throttle units: various fixed and/or hand held units that are used by operators to communicate to the 'system' relating to things like speed and other functions relating to operation.
Most vendors sell a Command station/Booster combo unit: a command station with a booster built in. There are 'home grown' designs out there on the Internet (Google is your friend!) where you only build a booster unit (basically a power amp/modulator) and use your computer itself as the command station side of things. You would build throttle units that would connect to the computer somehow (lots of serial ports? WiFi LAN? RS485 (differencial variation of RS232) type 'LAN' (ala B. Chubb system).). Or the computer just runs the trains itself according to some program, with little or no human intervention at all.
You *should* be able to use any brand of decoder with any brand of 'system' -- the DCC signaling protocal (what is in the rails) itself is 'standard'. How the throttle units, command stations, and the booster units communicate amoungt themselves is something else. I.E. brandX boosters can only talk to a brandX command station and only brandX throttles can talk to a brandX command station (in general). Lenz has published an *open* protocal, XPressNet, which is how Lenz's products talks to each other. Digitrax has published a *proprietary* (somewhat closed) protocal, LocoNet, which is how Digitrax's products talks to each other. Both companies sell RS232 (and/or USB) to their 'net converter boxes/cables -- both 'nets are basically serial networks that operate at something like RS232 speeds and signal levels, but are bus oriented and use differential signals (ala RS485 or some variation).

Ignoramus322 spake thus:
Whoa. Back up just a second.
I'd like to take this discussion up one level to a bigger overview rather than the nuts-and-bolts details that folks have been giving you.
The answer to your question is yes, it is possible to control a DCC model railroad from a computer. But the unasked question is, how would this actually work?
The problem is this: while you can build and run a railroad that runs automatically from a computer, it's slightly more complicated than just telling the trains what to do. The problem is one of knowing where things are on the layout. So far, people have given you answers about how to control the trains, switches, etc., by a computer. But ask yourself this: how does the computer know where the trains are? How does it know when to accelerate and brake the trains, so they end up where they're supposed to be and don't crash into each other, or run through switches the wrong way?
To reach this level of automation, you not only need the standard DCC setup, but you need lots of sensors to tell you where things are at any given moment. This is a non-trivial problem. I don't have detailed knowledge of this myself, and would be curious to hear what others have to say about this.

David Nebenzahl skriver: That's correct.
There are tonnes of occupancy detectors out there that are DCC compatible. It is just a matte of choosing what system to use.
I'm using MpC (a German program) for DC trains (not DCC), the same program and hardware can be used with DCC.
Klaus

Well, um, in most normal things controlled by computers, there is some sort of feedback built in. I was assuming that there is such in these trains as well.
You raised a very interesting question.
i

Ignoramus322 skriver: None what so ever.
Klaus

Ignoramus322 spake thus:
Wrong assumption.
Think of DCC as a "write-only" system. In other words, you can send commands to devices (locomotives, headlights, switches, etc.), but you have no way of getting any feedback from those devices.
As Klaus pointed out, there are sensors you can install, like block occupancy detectors, but these don't have a very fine level of granularity. In other words, they'll tell you when a train (a loco, car, etc.) is within a certain block, but not exactly where within the block it is.
You can improve on this by installing things like photodetectors, where a beam of light is interrupted when a train passes through it. But it's still very tricky to correctly interpret this information so you avoid things crashing into each other.

David Nebenzahl skriver: That's why you install several detectors per block. In our case 3 detectors for a long block and 5 for a track with bi-directional trafiic.
Klaus

What you usually end up with is two 'networks': a mostly outbound network (computer => track) DCC and a mostly inbound network ('track' => computer). In some cases, one can partition things so that loco control is all that the DCC network handles and the 'other' network handles other things: turnouts, signals, block/OS occupancy. *My* thought for the 'other' network is the Bruce Chubb CMR/I system. This uses an RS485 type of network connecting one or more 'nodes', each of which has a batch of input and/or output 'ports'. There are some other options available (google is your friend!). The SMINI (Super Mini node) is ideal as a small 'substation' of I/O: one board with 3 input ports (x8 == 24 input pins) and 6 output ports (x8 = 48 OC (pullup or pulldown) output pins). Mount one of these under the table and wire upto 24 sensors (block/OS occupancy, turnouts state, etc.) and upto 48 devices (turnouts, signals, etc.), run the 5 conductor cable back to a RS232RS485 converter and connect the RS232 to a second RS232 port (the first being used for your DCC system) and there you are. If you need more I/O pins, you can either use a SUSIC (Super Classic Universal Serial Interface Card), which lives it is own bus backplane which can be filled with a pile of 32-bit Input and/or 32-bit Output cards. Or just scatter several SMINIs about the layout and 'daisy-chain' them. I have a small setup that demostrates this. Uses three SMINIs: One SMINI is on a section with a pair of back-to-back #8 turnouts leading up to a double track bridge (merges two single track routes to/from the double track bi-direction bridge) -- the SMINI manages the turnouts, signals, and turnout state (will also monitor block and OS occupancy as well, once I get that far with the layout). The second SMINI is on the section on the other end of the bridge (and handles the signals and (eventually) occupancy at that end), and the third SMINI is not on the 'layout', but on a control panel (a control 'tower') and is connected to the switches and LEDs on the control panel. All of the 'logic' of the junction is handled by the computer, with the option of either 'local' control: tower is 'manned' and the operator manages turnouts and signals or central control: tower is unmanned and the central dispatcher (sitting at his/the computer screen) has control. In theory, the computer itself could be the controlling agent (eg a software program playing the role of central dispatcher and/or tower operator).

Klaus D. Mikkelsen spake thus:
So how accurately can you locate a train running on your layout? And do you have any automated features operated by the detectors, or do they just drive a display?

Robert Heller spake thus:
[snip lotsa good stuff describing model RR I/O for DCC]
In theory, yes. In practice, it sounds like a gigantic migraine headache, especially cooking up the software to run it all. Definitely a non-trivial project. (Of course, were *I* to attempt to program this, I'd be working in super-paranoid mode with lots of error checks, so that in the worst case the damned thing would just shut down before any cornfield meets occurred.)

Right. I'd just start with *manual* (human) dispatching, with the computer performing error checks of various sorts, like strickly inforcing restricting signal aspects, speed limits, and locking out improper turnout controls (ie you can't change a turnout state if the turnout is itself occupied and such like).

David Nebenzahl skriver: 1 detector for the most of the block, and 2 at the end (1 for deacceleration and 1 for stop)
The whole layout is fully autoamted.
A little more than 1000 meter of H0 track, 65 running units, where between 10 and 20 is in motion at the same time.
Klaus

I have a description of these issues at