Randall Train Automation Controller:

“Conductor” and “RTAC” software

2017-11

Over the last year, I worked on automating the Randall Museum's layout, built by the Golden Gate Model Railroad Club.

This is an old HO DC layout that has been converted to DCC using an NCE command station and boosters.

The mainline turnouts are controlled using rotary toggles (non-momentary) that are directly connected to their corresponding Tortoise or PFM Fulgurex slow-motion turnout motors, as I explained here.

The layout is fairly large, and to get started we decided to only automate two parts of the layout: there are two specific routes, called the “passenger” and “branchline” routes, which are automated.

I proposed several other automated lines and if this initial phase works well, we might expand it later.

The automation is designed to be used by the museum staff and consequently the whole system is designed to be as seamless as possible.

Conductor

The automation is controlled by a Linux computer running JMRI, a custom Java program named “Conductor” and an Android application named “RTAC”, the “Randall Train Automation Controller”. I built Conductor and RTAC specifically for the Randall automation, yet they should be flexible enough to be reused for other train automation projects.

Features of Conductor:

  • Conductor is a Java app that integrates with JMRI.
  • It has access to the turnouts, sensors and throttles defined in JMRI.
  • Conductor is controlled using an automation script with a custom language that I developed for that purpose.
  • The script responds to sensor events and controls DCC turnouts and DCC engines via JMRI.
  • This allows the automation to be easily modified without recompiling the program.

That screenshot looks complex and probably intimidating.

Luckily, as I explain later, the museum staff will not have to interact with it.

The Conductor app is invoked from JMRI using its Jython extension bridge. Conductor’s main role is to run a script that drives the automation. It uses an event-based language I created for that purpose that updates turnouts and engines in reaction to a combination of sensors and timer inputs. Sensors can be either activation buttons or track occupancy sensors defined in JMRI. Depending on the state of the automation and the location of the engines, the script can change their speed, change the lights, blow the horn, set turnouts as required. It is essentially a fully automated DCC cab.

The Randall museum uses an NCE command station and boosters. Sensors are detected using NCE AIU modules. Turnouts are controlled using NCE Switch-8 or Digitrax DS64 modules. Since Conductor interfaces with JMRI, it is not specially tied to NCE hardware. It can interface with any throttle, sensor or turnout that can be controlled via JMRI.

One key feature of the automation script is that it is both timer-based and sensor-based. Model train motors are analog and their speed and running is not precise enough for automation. The only way for an automation to be reliable is to physically know the location of the train on the track, which is typically done using block occupancy sensors. The track is divided in blocks and electrical sensors detect when a train enters and leaves specific blocks. These events are precise as they are directly related to specific locations on the track that are known and never change. Such location events are ideal to control the speed of the train, to tell it to start, accelerate, stop, etc. Timer events are good enough for less critical tasks like blowing the train horns. Usually both techniques are combined, which results in excellent control, for example a train can be set to stop after entering a block with a delay so that it actually stops in front of a station when taking momentum into account and can then leave after a specific time.

For ease of developing and testing, the Conductor app also has a second custom language to simulate the automation. This simulates the progression of the train through the layout, simulating the activation of track occupancy sensors as if the actual engines were moving along.

Here’s an example of the event-based script on the left and the simulation script on the right:

In this example the piece of script on the left above indicates that when the train is stopped on block B503b (the main passenger station) and the activation button is pressed, turn on the train sound & lights and start moving at a reduced station speed. After 2 seconds, blow the horn. Once the train reaches block B503a, accelerate to full speed.

On the right side, the simulation script waits for the same activation button to be pressed and once pressed simulates the train moving from block B503b to B503a after 8 seconds. The simulation script can then be used to test the automation script even when the computer is not connected to the layout and no train is actually moving. Once the simulation is perfected, the system can be connected to the layout to try with actual trains.

RTAC

Once the system will be installed on the Randall layout definitively, the staff in charge will not have to access the computer. It will essentially run as a “headless” computer hidden away under the layout, set to automatically turn on when the layout’s power is turned on and then to automatically shutdown when the layout power is turned off.

To be able to easily interact and monitor the state of the automation, two tablets are provided that run a custom Android app named “RTAC”, which is the visible part of the “Randall Train Automation Controller”.

Features of RTAC:

  • RTAC is a custom Android app that runs on two tablets.
  • It’s synchronized with Conductor to display the automation status and the track occupancy.
  • RTAC automatically connects to the Conductor server using the Zeroconf protocol.
  • RTAC features an “Emergency Stop” which users can use to stop the automation, for example if a train derails. Once the Conductor software goes in emergency stop, the tablet can be used to reset the system with some clear indication on screen of what to do.
  • Both tablets are synchronized so that the display is the same on both and either can be used to trigger the emergency stop or reset the automation.

The Conductor app is also a server. It communicates with the two tablets to display the status of the automation and the track occupancy. The tablets are connected over wifi with the same private network as the computer driving the automation. The Conductor app and the tablets find each other using Zeroconf; no configuration is needed on the tablet side.

The tablet software is designed to operate in “kiosk mode” meaning that as soon as the tablet is turned on, the RTAC software takes over and prevents users from doing anything else with the tablet. Normally only the museum staff should have access to these tablets, and they should not be able to close or dismiss the app by mistake.

Pressing the “E-Stop” (Emergency Stop) button on either tablet asks for a confirmation dialog. Once the staff confirms the order, the Conductor app stops the train immediately using the NCE/DCC emergency stop command (which means trains stop immediately, regardless of their decelerating momentum). The staff is then instructed to bring back the trains to their expected origin location and then reset the automation.

Although Conductor and RTAC are specific to the Randall Museum's layout for now, they are designed to be flexible and be reused to automate other model train layouts. The source is available here. Please contact me if interested.

~~

[Back to main page]

~~